Repository navigation
OSAC-2921: PRD — Add standardized display_name and description fields to resource Metadata - #141
Conversation
WalkthroughAdds a PRD defining shared ChangesMetadata display name specification
Estimated code review effort: 1 (Trivial) | ~5 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 11✅ Passed checks (11 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
AI EP Review: EP-141Score: 9/10 | Verdict: PASS
Verdict: A clean, well-structured PRD with clear user-facing outcomes, strong persona coverage, and no design leakage — held back only by a generic business justification that lacks quantified impact or strategic tie-in. Feedback: Strengthen the WHY: add concrete evidence such as the number of resource types currently lacking friendly names, user feedback or support tickets about the limitation, or tie to a strategic goal like UI consistency for a specific milestone or customer adoption blocker. Also declare which OSAC services are in scope (or state 'all services') and explicitly note whether the Cloud Infrastructure Admin persona is affected or unaffected. Critical (0)None. Important (3)
Suggestions (3)
Review costModel: claude-opus-4-6 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@enhancements/OSAC-2921-metadata-display-name/prd.md`:
- Around line 18-19: Update the requirements around display_name filtering,
sorting, and API responses to explicitly define effective-name behavior across
UI, CLI, and API: use display_name when set and metadata.name otherwise for
filtering and sorting, and state whether APIs expose the raw optional
display_name, the effective label, or both. Ensure all interfaces follow the
same documented behavior.
- Around line 28-29: Normalize the resource name casing across the two scope
statements: use one canonical spelling for the bare-metal instance template in
both the template-parameter and flat-shape resource lists. Update only the
inconsistent BaremetalInstanceTemplate/BareMetalInstanceTemplate references in
the document.
- Around line 16-17: Expand the reconciliation requirements for removed
spec.title and spec.description fields for Project, Role, IdentityProvider, and
InstanceType: define migration of existing values into metadata, precedence when
both legacy spec fields and new metadata fields are present, and compatibility
behavior for legacy reads and updates. Preserve the stated optional, mutable,
and clearable semantics.
- Around line 15-17: Clarify the metadata validation and clearing contract for
display_name and description: specify whether maximum lengths count Unicode
characters or bytes, define distinct behavior for empty strings, null, omitted
fields, and whitespace-only values, and state whether length validation occurs
before or after normalization. Update the surrounding PRD requirements so these
semantics are explicit and testable.
- Around line 15-16: Clarify the metadata adoption and precedence rules for
flat-shape resources in the PRD, including whether they expose both shared
display_name/description and existing title/description fields. Define which
field is authoritative for UI display, API responses, filtering, and sorting
when both are present, and align the related statements at lines 15 and 28-29.
🪄 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: osac-project/coderabbit/.coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: 066a7618-ea32-4b35-afd6-51f1af629003
📒 Files selected for processing (1)
enhancements/OSAC-2921-metadata-display-name/prd.md
| - Removal of existing `title` and `description` fields from the spec of spec-based resources: Project, Role, IdentityProvider, and InstanceType (description only) `[Clarify: R1.Q1, R4.Q2, R5.Q2]` | ||
| - Both fields are optional, mutable after creation, and clearable `[Clarify: R3.Q1]` | ||
| - Users can filter and sort resource lists by `display_name` across UI, CLI, and API `[Clarify: R2.Q2]` | ||
| - UI displays `display_name` in place of `metadata.name` when set; falls back to `metadata.name` when `display_name` is not set — this applies uniformly across list views, detail pages, breadcrumbs, and search results `[Clarify: R4.Q1, R5.Q1]` |
There was a problem hiding this comment.
Maybe the backend should set display_name to metadata.name when it is not provided, so the UI (and CLI) has a single source for the name to display
There was a problem hiding this comment.
I disagree. The backend should not populate fields for the user. If it did, then during edit the user will not understand why the field has a value when they did not set it. The UI should know to fallback
There was a problem hiding this comment.
Good discussion. The PRD keeps the UI-side fallback approach (UI displays metadata.name when display_name is not set) rather than backend auto-population, per ygalblum's point about avoiding user confusion during edits. This can be revisited in the design phase if needed.
There was a problem hiding this comment.
Should the CLI do the same?
There was a problem hiding this comment.
Moot now — we've removed the display fallback requirement entirely and deferred display behavior to the UX team and design phase.
|
|
||
| ## Out of Scope | ||
|
|
||
| - Making `display_name` or `description` required for any resource type |
There was a problem hiding this comment.
The "in scope" section already defines these as optional, so we don't need this item
There was a problem hiding this comment.
Updated — removed the "Making display_name or description required" item from Out of Scope since the In Scope section already defines them as optional. Thanks for catching the redundancy.
|
|
||
| - Making `display_name` or `description` required for any resource type | ||
| - Renaming or removing existing `metadata.name` semantics | ||
| - Enforcing uniqueness constraints on `display_name` |
There was a problem hiding this comment.
This reads more like an "In scope" requirement: "display_name does not have to be unique"
There was a problem hiding this comment.
Done — moved to In Scope as a positive statement: "display_name does not have to be unique across resources".
| - Renaming or removing existing `metadata.name` semantics | ||
| - Enforcing uniqueness constraints on `display_name` | ||
| - Template parameter `title`/`description` fields within ComputeInstanceTemplate, BaremetalInstanceTemplate, and ClusterTemplate — only resource-level fields are affected `[Clarify: R1.Q3]` | ||
| - Flat-shape, platform-defined resources that already have top-level `title`/`description` fields: ClusterTemplate, ComputeInstanceTemplate, BareMetalInstanceTemplate, NetworkClass, HostType, ComputeInstanceCatalogItem, BareMetalInstanceCatalogItem, and ClusterCatalogItem — these keep their existing fields unchanged `[Clarify: R4.Q2, R5.Q2]` |
There was a problem hiding this comment.
What is the point of having both metadata.display_name and a resource-level title? Could the former replace the latter?
There was a problem hiding this comment.
+1 on this. We said that we don't want to keep the resource specific field. This change should remove any such specific field.
There was a problem hiding this comment.
There was a problem hiding this comment.
Those resource are provider-admin persona so that would change the scope, is that ok?
There was a problem hiding this comment.
Agreed — updated the PRD to remove title/description from ALL resource types, including flat-shape platform-defined resources (NetworkClass, HostType, catalog items, templates). The flat-shape exclusion is reverted. Also added a Cloud Infrastructure Admin user story to cover the persona impact.
…fields to resource Metadata Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: ushkalim <ushkalim@redhat.com>
…rces in scope Revert the flat-shape exclusion per reviewer feedback from sk-ilya and ygalblum. All 12 resource types with existing title/description fields now have them removed in favor of shared Metadata display_name and description. Added Cloud Infrastructure Admin user story, moved uniqueness to In Scope, and normalized BareMetalInstanceTemplate naming. Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: ushkalim <ushkalim@redhat.com>
AI EP Review: EP-141Score: 9/10 | Verdict: PASS
Verdict: A well-structured PRD with clear user stories across all four personas, specific behavioral requirements, and tight scope — held back only by a generic business justification that doesn't quantify impact or tie to strategic goals. Feedback: Strengthen the WHY by naming a concrete consequence: what breaks for users today, how many resources lack friendly names, or what adoption/support metric this blocks. A sentence like 'X% of resources have no display name, leading to Y' would move WHY from 1 to 2. Consider explicitly declaring which OSAC services are in scope (implied to be all, since Metadata is shared, but the PRD never states this). The cross-cutting dimensions checklist (installation, E2E testing details, documentation scope) could be addressed more explicitly, even if just to say 'covered by the shared Metadata change with no per-dimension variance.' Critical (0)None. Important (1)
Suggestions (3)
Review costModel: claude-opus-4-6 |
AI Design Review: EP-141Score: 1/8 | Verdict: FAIL
Verdict: This PR submits a PRD (prd.md) but no design document (design.md) — when evaluated against the design review rubric, it scores 0 on Architecture, Feasibility, and Testability because it contains none of the required implementation detail, proto schemas, or test plans that a design document must provide. Feedback: This PRD appears well-structured for its purpose (clear scope, good persona coverage, traceability to clarify rounds), but a design document (design.md) is needed alongside it. The design should include: (1) the updated Metadata proto schema with display_name and description fields, the migration plan for removing per-resource title/description from 12 resource types, and the generic_server.go/rendering changes; (2) a concrete test plan with unit tests for field validation, integration tests for migration, and e2e scenarios; (3) an Alternatives section (e.g., keeping per-resource fields vs. centralizing in Metadata, or using annotations vs. spec fields). Critical (4)
Important (3)
Suggestions (3)
Review costModel: claude-opus-4-6 |
mhrivnak
left a comment
mhrivnak
left a comment
There was a problem hiding this comment.
To me, a lot of the value that is being proposed here is a reach. We're not going to add new fields that establish unique identity. The name field is a very common convention that people use with k8s, podman, docker, leading cloud services, etc. without difficulty, so I'm having a hard time seeing that this proposal would make a significant improvement in usability that way. We also already have labels.
I could see that these fields are useful for display purposes. If a human looking at a list of clusters clicks on one, showing them a plain-language name and description for that cluster could be helpful as context. But that's about it. Anything to do with unique identity, sorting, auditing, labeling, etc. seems well-handled with the fields we have. I welcome you to make the case otherwise, but then it would help a lot to get specific and use some examples.
| ### Cloud Provider Admin | ||
|
|
||
| - As a Cloud Provider Admin, I want resources across all tenant organizations to show a consistent, human-readable `display_name` and `description` so that I can quickly identify and audit resources when reviewing or supporting tenants, regardless of resource type. | ||
| - As a Cloud Provider Admin, I want to filter and sort resource lists by `display_name` so that I can locate specific resources across tenants without memorizing DNS-label names. `[Clarify: R2.Q2]` |
There was a problem hiding this comment.
An example might help illustrate the value.
DNS-style names don't exactly require "memorization". Things like node03.cluster01.example.com are fairly easy to interpret. When you talk of filtering and sorting, having some structure typically makes that easier.
How would a "Display Name" be helpful, or even better, for filtering and sorting?
There was a problem hiding this comment.
I think the idea is that if the UI shows the display_name in the list view, it only make sense to allow the user to filter and sort by it.
There was a problem hiding this comment.
Ok that makes sense. Maybe then we should remove the part about memorization, and leave this at "As a Cloud Provider Admin, I want to filter and sort resource lists by display_name so that I can find resources by using natural language".
There was a problem hiding this comment.
Updated per consensus — reworded to "so that I can find resources across tenants using natural-language terms."
|
|
||
| ### Tenant Admin | ||
|
|
||
| - As a Tenant Admin, I want all resource types I manage (VMs, virtual networks, public IPs, security groups, etc.) to support a friendly `display_name` and `description` so that I can label and document resources meaningfully instead of being limited by `metadata.name` restrictions. |
There was a problem hiding this comment.
Labels are a different concept entirely.
Can you be more specific about what restrictions you want to overcome and why?
There was a problem hiding this comment.
Yeah, I think that's a bit of AI slop. Trying to give the tenant admin additional reasons why they would want ti
There was a problem hiding this comment.
Reworded — removed "label" (confused with Kubernetes labels) and clarified the constraint: "so that I can give resources a natural-language name and description that are not constrained to DNS-label format."
| ### Tenant User | ||
|
|
||
| - As a Tenant User, I want to give my resources a friendly `display_name` (up to 63 characters) and `description` when creating them so that I can identify and organize them more easily than relying on the constrained `metadata.name` field. `[Clarify: R2.Q1]` | ||
| - As a Tenant User, I want list views to show `display_name` when set and fall back to `metadata.name` when it is not, so that I always see the most useful identifier regardless of whether a display name was provided. |
There was a problem hiding this comment.
mixing these fields could lead to a confusing UX. I suggest we clearly define what each field is for and stick to it. That said, we can also let the UX experts decide when/if to display each piece of information to users.
name is clearly about establishing human-usable unique identity. Example: dell-xe9680
display_name could be about having a more natural name that aligns with how something is described in the real world. Example: Dell PowerEdge XE9680
There was a problem hiding this comment.
That said, we can also let the UX experts decide when/if to display each piece of information to users.
That's the behaviour defines by the UI.
name is clearly about establishing human-usable unique identity. Example: dell-xe9680
display_name could be about having a more natural name that aligns with how something is described in the real world. Example: Dell PowerEdge XE9680
This is exactly the point of this PRD. What do you think is missing to make it clear.
There was a problem hiding this comment.
I think it's generally a bad UX "to show display_name when set and fall back to metadata.name when it is not". As described, they have different purposes. I'd remove that requirement from this PRD. That doesn't prevent someone from doing it, but at least doesn't mandate it.
There was a problem hiding this comment.
I don't mind removing it and letting the UX make their decision later. At this point, the important part is to facilitate it.
The main reason for this PRD is the fact that some resource had it while other didn't. In the ones that did, some called it title and some display_name. So, we wanted to align it
There was a problem hiding this comment.
Removed the UI fallback requirement from the PRD and moved display behavior to Out of Scope — deferred to the UX team and design phase, per the consensus here.
There was a problem hiding this comment.
Agreed — the PRD now makes this distinction explicit: metadata.name for identity (stated in Out of Scope), display_name for natural-language naming. The example you gave (dell-xe9680 vs Dell PowerEdge XE9680) captures it well.
ygalblum
changed the title
|
@udis: This pull request references OSAC-2921 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the feature to target the "5.0.0" version, but no target version was set. 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. |
…avior Reframe In Scope to focus on concepts, personas, and coverage per mhrivnak's feedback. Remove UI fallback requirement and defer display behavior (how clients present display_name vs metadata.name) to UX team and design phase per mhrivnak and ygalblum consensus. Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: ushkalim <ushkalim@redhat.com>
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@enhancements/OSAC-2921-metadata-display-name/prd.md`:
- Line 19: Remove “E2E test coverage and documentation” from the PRD’s In Scope
list, and track these delivery artifacts in the design or implementation plan
instead. Keep the remaining In Scope items focused on product behavior.
- Line 17: Update the reconciliation statement in the PRD to remove only
spec-level title/description fields from Project, Role, IdentityProvider, and
InstanceType, while retaining existing fields on NetworkClass, HostType,
templates, and catalog items. Split the affected and retained resource lists,
and document how retained flat-shape fields coexist with shared metadata.
🪄 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: osac-project/coderabbit/.coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: a4787f05-e176-45b4-a397-f8dbfaecba8c
📒 Files selected for processing (1)
enhancements/OSAC-2921-metadata-display-name/prd.md
|
|
||
| - Consistent, user-friendly resource naming across all OSAC resource types, all personas, and all client interfaces (API, CLI, Web UI) `[PR review: mhrivnak]` | ||
| - Two new shared Metadata fields: `display_name` (optional, max 63 characters) and `description` (optional, max 256 characters) — both mutable, clearable, and not required to be unique `[Clarify: R2.Q1, R3.Q1, R4.Q4, PR review: sk-ilya]` | ||
| - Reconciliation of existing per-resource `title`/`description` fields — removed from all 12 resource types that currently have them: Project, Role, IdentityProvider, InstanceType (description only), ClusterTemplate, ComputeInstanceTemplate, BareMetalInstanceTemplate, NetworkClass, HostType, ComputeInstanceCatalogItem, BareMetalInstanceCatalogItem, ClusterCatalogItem `[Clarify: R1.Q1, PR review: sk-ilya, ygalblum]` |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
Align the removal list with the stated flat-shape boundary.
Line 17 removes fields from NetworkClass, HostType, templates, and catalog items, but the PR objective says only spec-level fields on Project, Role, IdentityProvider, and InstanceType are removed; flat-shape resources retain their existing fields. Split the lists and document how retained fields coexist with shared metadata.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@enhancements/OSAC-2921-metadata-display-name/prd.md` at line 17, Update the
reconciliation statement in the PRD to remove only spec-level title/description
fields from Project, Role, IdentityProvider, and InstanceType, while retaining
existing fields on NetworkClass, HostType, templates, and catalog items. Split
the affected and retained resource lists, and document how retained flat-shape
fields coexist with shared metadata.
There was a problem hiding this comment.
Declining this suggestion — it reflects an earlier scope that reviewers explicitly rejected.
@sk-ilya and @ygalblum asked to remove resource-level title/description from all affected resource types (including flat-shape platform resources). That is locked in the PRD (all 12 listed types). The PR description was stale and still described the old flat-shape split; it has been updated to match.
AI EP Review: EP-141Score: 9/10 | Verdict: PASS
Verdict: A solid, focused PRD with clear user-facing capabilities, comprehensive persona coverage, and testable requirements; held back slightly by a generic business justification that describes the gap without quantifying its impact. Feedback: Strengthen the WHY by adding concrete evidence of user impact — e.g., how many resource types lack friendly names today vs. how many have workarounds, whether this has surfaced as user feedback or blocked adoption, or how it relates to OSAC's competitive positioning. Also explicitly declare which services are in scope (likely all five) per the OSAC dimensions checklist, and consider noting which cross-cutting dimensions are not applicable to show they were considered. Critical (0)None. Important (2)
Suggestions (3)
Review costModel: claude-opus-4-6 |
Reword Cloud Provider Admin filter/sort story per mhrivnak/ygalblum consensus (natural-language terms instead of memorization). Reword Tenant Admin story to remove 'label' term (Kubernetes labels confusion) and clarify DNS-label format constraint. Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: ushkalim <ushkalim@redhat.com>
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
enhancements/OSAC-2921-metadata-display-name/prd.md (2)
18-18: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winDefine filtering and sorting behavior for unset names.
Because
display_nameis optional and display fallback is deferred, clarify whether filters match only explicitly set values, where unset values sort, and whether matching is case-sensitive. Otherwise API, CLI, and UI implementations can diverge.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@enhancements/OSAC-2921-metadata-display-name/prd.md` at line 18, Clarify the filtering and sorting requirements for the optional display_name in the PRD: specify whether filters include only explicitly set names, where unset names appear in sort order, and whether matching is case-sensitive. Document behavior consistently for API, CLI, and UI implementations.
16-16: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winMake validation and clearing semantics testable.
Specify whether limits count Unicode characters or bytes, whether normalization precedes validation, and how omitted,
null, empty, and whitespace-only values behave. Without this, services may apply inconsistent validation and clearing behavior.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@enhancements/OSAC-2921-metadata-display-name/prd.md` at line 16, Update the shared Metadata field specification for display_name and description to define whether length limits use Unicode characters or bytes, whether values are normalized before validation, and the exact handling of omitted, null, empty, and whitespace-only inputs. Document these rules so validation, mutation, and clearing behavior are consistent and testable across services.
♻️ Duplicate comments (2)
enhancements/OSAC-2921-metadata-display-name/prd.md (2)
19-19: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winMove delivery artifacts out of product scope.
Keep E2E coverage and documentation in the design or implementation plan;
In Scopeshould describe product behavior. Based on learnings, these deliverables are not expected in PRD scope sections.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@enhancements/OSAC-2921-metadata-display-name/prd.md` at line 19, Remove “E2E test coverage and documentation” from the PRD’s In Scope section. Keep these delivery artifacts in the design or implementation plan instead, ensuring the scope describes only product behavior.Source: Learnings
17-17: 🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy liftAlign the reconciliation scope and define migration behavior.
Line 17 removes fields from flat-shape resources, conflicting with the PR objective that templates, catalog items,
NetworkClass, andHostTyperetain their existing fields. It also does not define how existing values migrate into metadata, which field wins when both exist, or how legacy reads and updates behave. Split the affected and retained resource lists and specify these compatibility rules.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@enhancements/OSAC-2921-metadata-display-name/prd.md` at line 17, Update the reconciliation section in the PRD to separate resources whose existing title/description fields are removed from those that retain them, ensuring templates, catalog items, NetworkClass, and HostType remain in the retained list. Define migration of existing values into metadata, precedence when legacy and metadata values both exist, and compatibility behavior for legacy reads and updates.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@enhancements/OSAC-2921-metadata-display-name/prd.md`:
- Line 18: Clarify the filtering and sorting requirements for the optional
display_name in the PRD: specify whether filters include only explicitly set
names, where unset names appear in sort order, and whether matching is
case-sensitive. Document behavior consistently for API, CLI, and UI
implementations.
- Line 16: Update the shared Metadata field specification for display_name and
description to define whether length limits use Unicode characters or bytes,
whether values are normalized before validation, and the exact handling of
omitted, null, empty, and whitespace-only inputs. Document these rules so
validation, mutation, and clearing behavior are consistent and testable across
services.
---
Duplicate comments:
In `@enhancements/OSAC-2921-metadata-display-name/prd.md`:
- Line 19: Remove “E2E test coverage and documentation” from the PRD’s In Scope
section. Keep these delivery artifacts in the design or implementation plan
instead, ensuring the scope describes only product behavior.
- Line 17: Update the reconciliation section in the PRD to separate resources
whose existing title/description fields are removed from those that retain them,
ensuring templates, catalog items, NetworkClass, and HostType remain in the
retained list. Define migration of existing values into metadata, precedence
when legacy and metadata values both exist, and compatibility behavior for
legacy reads and updates.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: osac-project/coderabbit/.coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 47bb6971-1789-4d5b-b777-77ec102df594
📒 Files selected for processing (1)
enhancements/OSAC-2921-metadata-display-name/prd.md
AI EP Review: EP-141Score: 9/10 | Verdict: PASS
Verdict: A well-structured, user-focused PRD with strong persona coverage and coherent scope; the only weakness is a business justification that describes the inconsistency without connecting it to a strategic goal or quantified user impact. Feedback: Strengthen the WHY by connecting the inconsistency to a concrete business outcome — e.g., does the lack of friendly names cause support tickets, slow down tenant onboarding demos, or block UI features that depend on display names? One sentence tying the pain to platform adoption or a specific user complaint would lift WHY from 1 to 2. Consider also explicitly naming which OSAC services are in scope (all of BMaaS/CaaS/VMaaS/MaaS/Enclave, since metadata is cross-cutting) to satisfy the dimensions checklist. Critical (0)None. Important (1)
Suggestions (3)
Review costModel: claude-opus-4-6 |
Remove E2E/documentation from In Scope (delivery artifacts belong in design/implementation). Reply round addresses CodeRabbit and mhrivnak top-level feedback. Assisted-by: Claude Code <noreply@anthropic.com>
|
@mhrivnak Thanks — we've narrowed the PRD around that feedback:
Happy to adjust further if this still overclaims. |
AI EP Review: EP-141Score: 9/10 | Verdict: PASS
Verdict: Strong PRD with clear user-facing need, concrete justification, focused scope, and testable requirements; the only weakness is minor design leakage in the reconciliation scope and dependencies section. Feedback: Reframe the reconciliation In Scope bullet as a user outcome ('All OSAC resources use the same display_name and description fields, replacing the per-resource title/description fields used by some resource types today') instead of listing 12 internal resource types as implementation work items. Move the Dependencies section content (fulfillment-service proto ordering) to the design document — a PRD should state what depends on what from the user's perspective, not which internal components must land first. Consider explicitly listing which services are in scope (even if all of them) and adding a brief note on cross-cutting dimensions like documentation and E2E testing scope. Critical (0)None. Important (2)
Suggestions (4)
Review costModel: claude-opus-4-6 |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mhrivnak, udis 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 |
5 participants
PRD: Add standardized display_name and description fields to resource Metadata
Jira: https://redhat.atlassian.net/browse/OSAC-2921
Summary
This PRD proposes adding
display_name(max 63 chars) anddescription(max 256 chars) as optional fields on the shared Metadata struct, giving every OSAC resource type a consistent, user-friendly naming mechanism. Existing per-resourcetitle/descriptionfields are removed from all 12 resource types that currently have them (including flat-shape platform-defined resources such as templates, catalog items, NetworkClass, and HostType) in favor of the shared Metadata fields.Requesting Review On
title/descriptionfrom all affected resource typesmetadata.name; display behavior deferred to UX/designdisplay_nameand 256-chardescriptionlimitsHow to Review