General

You should try to use a Jira MCP server to create any Jira items or issues.

Any HyperShift feature, epic, story, or task should be created in the Jira project known as Red Hat OpenShift Control Planes also known as CNTRLPLANE.

Any request to make a bug ticket or make the content for a bug ticket should go under the Jira project known as OpenShift Bugs, also known as OCPBUGS.

Set the Jira component to:

• HyperShift / ARO - when the issue is about ARO HCP
• HyperShift / ROSA - when the issue is about ROSA HCP
• HyperShift - when it is not clear if the issue is about a particular HyperShift platform

When you create a Jira issue, add this label: ai-generated-jira.

By default, set the Security Level to the following: Red Hat Employee.

Never include credentials or secrets in any Jira issue (e.g., usernames/passwords, cloud keys, API tokens, kubeconfigs, SSH keys, certificates). This applies to descriptions, comments, attachments, screenshots, logs, and URLs. Redact before sharing.

Use Jira’s native description formatting (Wiki/ADF): headings, bullet lists, code blocks, and tables.

Standard Parts of a Jira Issue

Summary

A summary is a brief text synopsis of the issue.

It answers the questions - How do we typically refer to this issue?

A summary is needed for the following Jira issue types: Outcomes, Features, Initiatives, Epics, Stories, Spikes, Tasks, Bugs, Tickets, Risks, Sub-Tasks.

Setting Versions

For any Jira story or task, unless specified differently from the user, the target version (also known as customfield_12319940) should always be openshift-4.21.

For any OCPBUGS Jira issue, the affected version/s and target version (also known as customfield_12319940) fields should default to 4.21.

Never set the Fix Version/s or fixVersions fields.

Instructions on specific Jira Issue components

Creating a feature

TBD

Creating an epic

Summary: An agile epic is a body of work that can be broken down into specific items (called user stories) based on the needs/requests of customers or end-users. Epics are an important practice for agile and DevOps teams. When adopting agile and DevOps, an epic serves to manage work.

In an epic, the epic name field is required. Make it the same as the summary field.

The parent link field is where the feature ID would be specified to which the epic belongs.

Epics should:

• be a more narrow strategic objective than a market problem
• be broader than a user story
• fit inside the time box (quarter/release) and stories should fit inside a sprint
• typically include acceptance criteria (this lets us know when the epic is done!)

Creating a story

A story describes product functionality from a customer’s perspective.

It is a collaboration tool – a reminder to have a conversation about what the customer needs so the team can design it well & deliver it quickly.

Stories...

• Shifts the focus from writing to talking – words are imprecise
• Supports satisfying customer through early and continuous delivery of valuable software
• Involves users, domain experts and stakeholders (i.e. customers) in a creative, iterative, collaborative design process
• Describes concrete business reference scenarios, equally understandable by developers and customers in common, shared language
• Product Manager / Team Lead ranks stories in teams’ work queue according to relative business value, and team designs iteratively & delivers incrementally
• Developers and customers in common, shared language
• The right size for planning – level of detail is based on implementation horizon
• Three components (3 Cs) of a User Story: Card, Conversation, Confirmation (Acceptance Criteria)

User Story Template

Description

The description should include:

As a<User/Who>, I want to <Action/What>, so that <Purpose/Why>.

<User/Who> is the description of the person, device, or system that will benefit from or use the output of the story. <Action/What> is what they can do with the system <Purpose/Why> is why they want to do the activity.

The description should also include acceptance criteria:

• Expresses the conditions that need to be satisfied for the customer
• Provides context for the team, more details of the story, and helps the team know when they are done
• Provides the details of the story from a testing point of view
• Written by the Product Owner or dev team members
• Refined by the agile team during backlog grooming and iteration planning

Formats for Acceptance Criteria Test that

• or - Demonstrate that
• or - Verify that when does they get
• or - Given when then

Determining Amount of Acceptance Criteria - you have enough AC when:

• You have enough to size the story
• Testing will become too convoluted
• You have made 2-3 revisions of the criteria
• With more AC, split story into more stories

Creating a task

TBD

Creating a bug ticket

The summary, component, and affects version/s fields are required for all OCPBUGS Jira issues.

The description should include the following content:

• Description of problem:
• Version-Release number of selected component (if applicable):
• How reproducible:
• Steps to Reproduce:
• Actual results:
• Expected results:
• Additional info: