NO-JIRA: Add Jira process documentation for Definition of Ready and Verified#16352
NO-JIRA: Add Jira process documentation for Definition of Ready and Verified#16352jhadvig wants to merge 1 commit intoopenshift:mainfrom
Conversation
|
@jhadvig: This pull request explicitly references no jira issue. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
openshift-ci-robot
added
the
jira/valid-reference
openshift-ci
Bot
added
the
approved
📝 WalkthroughWalkthroughThis pull request adds two new documentation files to the console repository's process directory. The first establishes a "Definition of Readiness" that specifies mandatory fields for Jira issues (bugs require problem description, version details, reproducibility information, and severity; stories require objectives, user stories, UX designs, and test cases with criteria). The second document defines the "Verified" process for pull reviews, outlining three reviewer phases: confirming Jira readiness, performing code review with test coverage expectations, and completing functional verification through manual testing before applying the 🚥 Pre-merge checks | ✅ 12✅ Passed checks (12 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
docs/process/definition-of-readiness.md (1)
47-47: Make Story component requirement explicit.Line 47 is currently underspecified (
Components) compared with the Bug section’s explicitManagement Consolerequirement. For machine-driven readiness checks, define required value(s) here as well.Suggested wording
-* **Components** +* **Components:** Management Console🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/process/definition-of-readiness.md` at line 47, Update the "Components" entry so it explicitly lists required component values for readiness checks (e.g., include "Story" as a required component similar to how the Bug section requires "Management Console"); edit the heading or bullet under Components to name the exact required component(s) ("Story") and any acceptable variants/case, so machine-driven checks can match them unambiguously.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/process/definition-of-verified.md`:
- Around line 16-20: Change the wording that refers to "/lgtm" and "/verified"
as labels to call them reviewer "commands" instead: update the lines under the
"Functional verification" section that currently read "Provides /lgtm label" and
"Provides /verified label" to instead read "Provides /lgtm command" and
"Provides /verified command" so the doc correctly reflects Prow reviewer
commands.
---
Nitpick comments:
In `@docs/process/definition-of-readiness.md`:
- Line 47: Update the "Components" entry so it explicitly lists required
component values for readiness checks (e.g., include "Story" as a required
component similar to how the Bug section requires "Management Console"); edit
the heading or bullet under Components to name the exact required component(s)
("Story") and any acceptable variants/case, so machine-driven checks can match
them unambiguously.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 17e2bea6-8153-4bae-a604-83f7f183bfc1
📒 Files selected for processing (2)
docs/process/definition-of-readiness.mddocs/process/definition-of-verified.md
📜 Review details
🧰 Additional context used
🪛 LanguageTool
docs/process/definition-of-readiness.md
[style] ~42-~42: Consider a more concise word here.
Context: ...ns * Test Cases * Optional - in order to open the Jira Story * Required -...
(IN_ORDER_TO_PREMIUM)
[style] ~43-~43: Consider a more concise word here.
Context: ...open the Jira Story * Required - in order to call the Jira Story Ready * Con...
(IN_ORDER_TO_PREMIUM)
🔀 Multi-repo context openshift/console-operator
Linked repositories findings
openshift/console-operator
-
Documentation / AI assistant config present:
- AGENTS.md documents Custom Claude Code Commands and AI assistant usage, indicating this repo has existing AI automation docs and conventions that may be relevant to the PR's machine-readable process docs. [::openshift/console-operator::AGENTS.md]
- CLAUDE.md and .claude/settings.json are present and reference Claude Code configuration (e.g., "Bash(claude --version)"), showing active Claude integration points where the new docs might be consumed. [::openshift/console-operator::CLAUDE.md] [::openshift/console-operator::.claude/settings.json]
-
Other places referencing Jira / annotations:
- vendor/github.com/openshift/api/README.md contains examples mentioning reporting problems to a Jira component and notes about required labels for the repository, suggesting existing Jira-related conventions in vendor code. [::openshift/console-operator::vendor/github.com/openshift/api/README.md]
- vendor/.../annotations/annotations.go references a jira component in OCPBUGS, indicating shared annotation keys used for Jira mapping. [::openshift/console-operator::vendor/github.com/openshift/api/annotations/annotations.go]
- .coderabbit.yaml includes a "jira:" section, showing another automation configuration that references Jira. [::openshift/console-operator::.coderabbit.yaml]
Assessment: the repository contains multiple AI-automation and Jira-related configuration/docs (AGENTS.md, CLAUDE.md, .claude, .coderabbit.yaml, vendor annotations). These are direct cross-repo signals that the new docs (definition-of-readiness.md and definition-of-verified.md) could be consumed by existing Claude / automation tooling here; reviewers should verify alignment with the existing AGENTS/Claude configuration and any expected schema/keys used by those tools. [::openshift/console-operator::]
🔇 Additional comments (1)
docs/process/definition-of-verified.md (1)
7-20: Good phased verification model.The three-phase split (readiness assessment, code review, functional verification) is clear and actionable for reviewers.
| * Provides /lgtm label | ||
| 3. Functional verification | ||
| * Manual testing of the change based on the provided Test Cases | ||
| * Automated CI testing is green | ||
| * Provides /verified label |
There was a problem hiding this comment.
Use “command” instead of “label” for /lgtm and /verified.
Line 16 and Line 20 currently describe these as labels, but they are reviewer commands in Prow workflows. Please adjust terminology to avoid process/tooling ambiguity.
Suggested wording
- * Provides /lgtm label
+ * Issues the `/lgtm` command
...
- * Provides /verified label
+ * Issues the `/verified` command📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| * Provides /lgtm label | |
| 3. Functional verification | |
| * Manual testing of the change based on the provided Test Cases | |
| * Automated CI testing is green | |
| * Provides /verified label | |
| * Issues the `/lgtm` command | |
| 3. Functional verification | |
| * Manual testing of the change based on the provided Test Cases | |
| * Automated CI testing is green | |
| * Issues the `/verified` command |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/process/definition-of-verified.md` around lines 16 - 20, Change the
wording that refers to "/lgtm" and "/verified" as labels to call them reviewer
"commands" instead: update the lines under the "Functional verification" section
that currently read "Provides /lgtm label" and "Provides /verified label" to
instead read "Provides /lgtm command" and "Provides /verified command" so the
doc correctly reflects Prow reviewer commands.
Add Definition of Ready and Definition of Verified documents under docs/process/ to serve as the source of truth for Jira issue readiness criteria and PR verification standards. These documents are consumed by Claude Code skills for automated bug triage and implementation. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
@jhadvig: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jhadvig, TheRealJon The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
3 participants
Analysis / Root cause:
The Console team is integrating AI tools into its development workflow. These tools need a machine-readable source of truth for issue readiness criteria and PR verification standards to perform automated triage and implementation.
Solution description:
Add two process documents under
docs/process/:definition-of-ready.md— defines the mandatory and optional Jira fields required before the team picks up a bug or story. All fields are mandatory unless explicitly marked optional (Priority, Target Backport Versions). Browser defaults to Chrome:latest. Artifacts require at least one, linked in the description or comments.definition-of-verified.md— defines the PR reviewer responsibilities: readiness assessment, code review (with test coverage expectations), and functional verification.These documents serve as input for Claude Code skills that automate bug triage, implementation, and PR review workflows.
Screenshots / screen recording:
N/A — documentation only.
Test setup:
N/A
Test cases:
N/A
Browser conformance:
N/A
Additional info:
These documents are consumed by the
/jira-bugClaude Code skill for automated readiness assessment, and will also be used by a future external/jira-storyskill.🤖 Generated with Claude Code
Summary by CodeRabbit