Skip to content

Latest commit

 

History

History
155 lines (108 loc) · 6.34 KB

issues-and-triage.adoc

File metadata and controls

155 lines (108 loc) · 6.34 KB
Raw

This page describes how we track issues in JIRA for Red Hat OpenShift Dev Spaces.

Issue Triage

New issues are automatically assigned to a component owner when one is set at the time the issue is created.

Issues created without a component or assignee need to be reviewed by a project committer (triage curator) who will set:

  • component(s),

  • label(s),

  • affects version(s),

  • release note related fields/flags, incuding writer if known,

  • priority/severity.

If known at the time of triage, curator can also set:

  • fix version and

  • assignee.

Triage process

All issues in the following JIRA filters should be reviewed daily by a curator so that the queries return no results.

Additionally, these queries should be checked regularly to ensure the number of issues is decreasing over time.

You can add issue counts per query here:

Steps to triage an issue:

  1. Verify:

    • The issue is not a duplicate

    • The issue has all the needed information

    • If the issue is a bug, it must include:

      • steps to reproduce it

      • product and platform versions & workspace details (OCP, Dev Spaces, devfile/project/sample used)

    • If the issue is not a bug:

      • the issue type must be set correctly (Task, QE Task, Enhancement, Epic, etc.)

  2. Set a component so the issue will be seen by the relevant people

  3. Set any relevant labels to assist sprint planning, prioritization, and review by Docs, PM, CEE, and other stakeholders

  4. Set Affects Version if not set but the issue description implies it

For some issues, you may be able to add even more information:

  1. Set Assignee if not set and work will begin immediately; remove assignee if work is not scheduled

  2. Set Fix Version if known/obvious; empty and "3.x" versions can be set to a more concrete value during sprint planning

  3. Set Priority if default “major” is not correct.

    Note

    Don’t change priority if the issue has a label need-PM/Support-triage. Instead, talk to the Product Manager or Support person for the related product (Dev Spaces, DWO, or WTO). You can message on Slack if they’re online, or leave a comment on the JIRA for them if they’re not.
    Note

    • label cee_high has priority = [mostly Critical, but could be Blocker]

    • label cee_medium has priority = [mostly Major, but could be Critical]

    • label cee_low has priority = Major or lower

  4. Set release note fields if relevant:

    • Affects: Release Notes

    • Release Note Text

    • Release Note Type

    • Release Note Status = Proposed, Rejected, None

    • Writer (if known)

  5. In general, if you’re not sure what to do, ask in Slack @ #forum-devspaces or @team-devspaces.

    Or, try one of these approaches:

    • Set the need-triage label so the next triager can review

    • Set the need-PM/Support-triage label if PM or Support should review

    • Ask for more info from the reporter and @mention them

    • If reporter is an authorised member of the CRW JIRA, assign issue to the reporter

Notification of triage results

At the end of their working day the curator reports the triage summary in Slack @ #forum-devspaces

The same person should do upstream and downstream triage that day.

Please also add a row of data to this table:

Issue Labels

Dev Spaces uses the following labels, but you are welcome to add more or use others.

Docs, Support, Security & Planning:

  • noteworthy

  • user-experience, cee, cee_low, cee_medium, cee_high, cee.neXT

  • current-sprint, next-sprint, sprint/next, sprint/current

  • Customer1, Customer2, Customer3, Customer4

  • tech-debt, tech_debt, technical-debt, tech-preview

  • CVE-yyyy-number, Security, SecurityTracking, pssc, pssc-ess, prodsec, legal

  • need-PM/Support-triage, need-triage

Architecture, Testing & Environments:

  • x86_64, IBM_Z, s390x, IBM_Power, ppc64le, Z/P

  • rhel9

  • airgap

  • e2e-failure

  • testing, qe-ci, releasework

  • workflow, error_handling, error_message, automation-gap

Features:

  • channel, operator

  • vscode-as-default, vscode-extension

  • git, oauth

  • regression

  • udi, python, java

Triage curators

See Triage curators for the latest rota.

Triage FAQ

Should the curator try to reproduce all the issues?

The curator doesn’t have the time to reproduce every issue. If reproducing an issue takes more than 15 min they should delegate it to a team. This is done through proper issue labeling, setting a component, and setting an assignee to review the issue.

Should the curator set the issue milestone?

The curator should not set the fixversion but, if the issue is a blocker, it must be part of the current release. If not a blocker, fix version will depend on the team’s bandwidth and on the risk of regression. If the curator is not able to determine if an issue is a blocker, they should ask questions on slack.