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
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: