openshift-eng/create-feature-request

Create Jira Feature Request

This skill provides implementation guidance for creating Feature Requests in the RFE Jira project, which captures customer-driven enhancement requests.

When to Use This Skill

This skill is automatically invoked by the /jira:create feature-request RFE command to guide the feature request creation process.

Prerequisites

• MCP Jira server configured and accessible
• User has permissions to create issues in the RFE project
• Understanding of the customer need and business justification
• Knowledge of affected components/teams

Reference Documentation:

• Markdown for Jira Reference - Markdown formatting for Jira descriptions

What is a Feature Request?

A Feature Request (RFE) is:

• A customer-driven request for new functionality or enhancement
• Submitted to the RFE project in Jira
• Captures business requirements and customer justification
• Links specific components and teams that need to implement the request
• Focuses on what is needed rather than how to implement it

Feature Request vs Feature vs Story

| Type | Purpose | Project | Example | |------|---------|---------|---------| | Feature Request (RFE) | Customer request for capability | RFE | "Support for Foo in ProductA managed control planes" | | Feature | Strategic product objective | CNTRLPLANE, etc. | "Advanced hosted control plane security" | | Story | Single user-facing functionality | Any | "User can upload custom SSL certificate via console" |

Feature Request Characteristics

Feature Requests should:

• Clearly state the customer need or problem
• Provide business justification for the request
• Identify affected components and teams
• Be customer-focused (what they need, not how to build it)
• Include enough detail for engineering teams to understand and estimate

Feature Request Description Best Practices

Title

The title should be:

• Clear and concise (50-80 characters)
• Customer-focused (describes the capability needed)
• Specific (not vague or overly broad)

Good examples:

Support Foo for ProductA managed control planes
Enable pod autoscaling based on custom metrics
Multi-cluster backup and restore for ProductB

Bad examples:

Better security (too vague)
SSL stuff (not specific)
Make autoscaling work better (not clear)

Nature and Description

Clearly describe:

• What is being requested (the capability or enhancement)
• Current limitations or gaps (what doesn't work today)
• Desired behavior (what should happen)
• Use case (how customers will use this)

Good example:

## Nature and Description of Request

Customers need the ability to use Foo for ProductA managed control plane endpoints, rather than relying on vendor-provided defaults.

### Current Limitation
Today, ProductA clusters use vendor-managed configuration for the API server endpoint. Customers cannot provide their own configuration, which creates issues for:
- Corporate security policies requiring organization-specific settings
- Integration with existing enterprise infrastructure
- Compliance requirements (SOC2, ISO 27001)

### Desired Behavior
Customers should be able to:
- Upload their own configuration during cluster creation
- Rotate configuration after cluster creation
- Validate configuration before cluster becomes active
- Receive alerts when configuration changes are needed

### Use Case
Enterprise customers with strict security policies need all infrastructure to use internally-managed configuration. This blocks ProductA adoption in regulated industries (finance, healthcare, government) where configuration management is a compliance requirement.

Bad example:

We need better SSL support.

Business Requirements

Explain why the customer needs this:

• Business impact (what happens without this)
• Customer segment affected (who needs this)
• Regulatory/compliance drivers (if applicable)
• Competitive context (if relevant)
• Priority indicators (blocking deals, customer escalations)

Good example:

## Business Requirements

### Customer Impact
- **Primary segment**: Enterprise customers in regulated industries (finance, healthcare, government)
- **Affected customers**: 10+ customers have requested this capability
- **Deal blockers**: Multiple active deals blocked by this limitation
- **Escalations**: Several P1 customer escalations due to compliance failures

### Regulatory Requirements
- SOC2 Type II compliance requires organization-specific configuration
- ISO 27001 mandates lifecycle management
- Financial services regulations (PCI-DSS) require integration with enterprise infrastructure
- Government contracts require validated configuration chains

### Business Justification
Without this capability:
- Cannot close enterprise deals in regulated industries
- Risk losing existing customers to competitors during renewals
- Increasing support burden from compliance audit failures
- Limiting market expansion into high-value segments

### Competitive Context
Major competitors (CompetitorA, CompetitorB, CompetitorC) all support this capability for managed Kubernetes control planes. This is a gap that affects product competitive positioning.

Bad example:

Customers need this for security.

Affected Packages and Components

Identify:

• Teams that need to implement this (use team names like "HyperShift", "ROSA SRE")
• Operators or controllers affected (e.g., "cluster-ingress-operator")
• Components in Jira (this will be set as the Component field)
• Related services (APIs, CLIs, consoles)

Good example:

## Affected Packages and Components

### Teams
- **HyperShift Team**: Control plane infrastructure, configuration management
- **ROSA SRE Team**: Operational validation, configuration rotation
- **OCM Team**: Console and API for configuration upload
- **Networking Team**: Networking and configuration distribution

### Technical Components
- **cluster-ingress-operator**: Configuration provisioning and installation
- **hypershift-operator**: Control plane configuration
- **openshift-console**: UI for configuration upload and management
- **rosa CLI**: CLI support for configuration operations

### Jira Component
Based on the primary team and technical area, this should be filed under:
**Component**: HyperShift / ProductA

### Related Services
- Product API (configuration upload endpoint)
- Configuration management service (validation, storage)
- Control plane API server (configuration installation)

Note: The "Jira Component" will be used to set the components field when creating the issue.

Interactive Feature Request Collection Workflow

When creating a feature request, guide the user through these specific questions:

1. Proposed Title

Prompt: "What is the proposed title for this feature request? Make it clear, specific, and customer-focused (50-80 characters)."

Validation:

• Not too vague ("Better performance")
• Not too technical ("Implement TLS 1.3 in ingress controller")
• Customer-facing capability

Example response:

Support Foo for ProductA managed control planes

2. Nature and Description

Prompt: "What is the nature and description of the request? Describe:

• What capability is being requested
• Current limitations
• Desired behavior
• Use case"

Probing questions if needed:

• What doesn't work today that should?
• What would you like to be able to do?
• How would customers use this capability?

Example response:

Customers need to use Foo for ProductA API endpoints instead of vendor-provided defaults.

Current limitation: ProductA only supports vendor-managed configuration, blocking customers with corporate requirements.

Desired behavior: Customers can upload, validate, and rotate custom configuration for the control plane API.

Use case: Enterprise customers in regulated industries (finance, healthcare) need organization-specific configuration for compliance.

3. Business Requirements

Prompt: "Why does the customer need this? List the business requirements, including:

• Customer impact and affected segment
• Regulatory/compliance drivers
• Business justification
• What happens without this capability"

Helpful questions:

• Who is asking for this? (customer segment)
• Why is this blocking them? (compliance, policy, competitive)
• What is the business impact? (deals, escalations, churn risk)
• Are there regulatory requirements?

Example response:

Customer impact:
- 10+ enterprise customers have requested this
- Multiple active deals blocked
- Several P1 escalations from compliance failures

Regulatory requirements:
- SOC2, ISO 27001, PCI-DSS require organization-specific configuration
- Government contracts require validated configuration chains

Business justification:
- Cannot close deals in regulated industries (finance, healthcare, government)
- Competitive gap (CompetitorA, CompetitorB, CompetitorC all support this capability)
- Risk of customer churn during renewals

4. Affected Packages and Components

Prompt: "What packages, components, teams, or operators are affected? This helps route the request to the right teams.

Provide details like:

• Team names (e.g., 'HyperShift', 'Networking', 'OCM')
• Operators (e.g., 'cluster-ingress-operator')
• Technical areas (e.g., 'control plane', 'API server')
• Services (e.g., 'OCM console', 'rosa CLI')"

Follow-up: After collecting this information, help the user determine the appropriate Jira Component value.

Component mapping guidance:

• If HyperShift, ProductA, or ProductB mentioned → Component: "HyperShift"
• If Networking, Ingress mentioned → Component: "Networking"
• If OCM, Console mentioned → Component: "OCM"
• If Multi-cluster, Observability mentioned → Component: "Observability"
• If unclear, ask: "Based on the teams and technical areas mentioned, which component should this be filed under?"

Example response:

Teams affected:
- HyperShift Team (primary - control plane configuration management)
- ROSA SRE Team (configuration rotation, operations)
- OCM Team (console UI for configuration upload)
- Networking Team (networking configuration distribution)

Operators/components:
- cluster-ingress-operator
- hypershift-operator
- openshift-console

Suggested Jira Component: HyperShift

Field Validation

Before submitting the feature request, validate:

Required Fields

• ✅ Title is clear, specific, and customer-focused
• ✅ Nature and description explains what is requested
• ✅ Business requirements justify why this is needed
• ✅ Affected components and teams are identified
• ✅ Jira Component is set to match the primary affected team or technical area
• ✅ Project is set to "RFE"
• ✅ Issue type is "Feature Request"

Content Quality

• ✅ Describes customer need (not implementation details)
• ✅ Business justification is clear
• ✅ Enough detail for engineering teams to understand
• ✅ No vague statements ("better performance", "more secure")
• ✅ Use case is explained

Security

• ✅ No credentials, API keys, or secrets in any field
• ✅ No confidential customer information (use anonymized references if needed)

MCP Issue Creation

Create feature requests via createJiraIssue with contentFormat: "markdown". Key parameters:

• projectKey: "RFE"
• issueTypeName: "Feature Request"
• summary: clear, customer-focused title
• description: formatted template (Markdown) with Nature/Description, Business Requirements, Affected Packages sections
• additional_fields: include "labels": ["ai-generated-jira"], "security": {"name": "Red Hat Employee"}

Jira Description Formatting

Use Markdown formatting with contentFormat: "markdown":

Feature Request Template Format

<Brief overview>

## Nature and Description of Request

<What is being requested>

### Current Limitation
<What doesn't work today>

### Desired Behavior
<What should work>

### Use Case
<How customers will use this>

## Business Requirements

### Customer Impact
- <Affected segment>
- <Number of requests>
- <Deal impacts>

### Regulatory/Compliance Requirements
- <Requirement 1>
- <Requirement 2>

### Business Justification
<Why this matters, impact of not having it>

### Competitive Context (optional)
<Competitor capabilities, market gaps>

## Affected Packages and Components

### Teams
- <Team>: <Responsibility>

### Technical Components
- <Component/operator>

### Related Services
- <Service>

## Jira Component
**Component**: <component name>

Error Handling

Missing Business Justification

Scenario: User provides feature request without clear business justification.

Action:

1. Explain importance of business requirements
2. Ask probing questions about customer impact
3. Help articulate business case

Example:

For a Feature Request to be prioritized, we need to understand the business impact.

Can you provide:
1. Who is requesting this? (customer segment, specific customers)
2. Why is it blocking them? (compliance, policy, competitive)
3. What is the business impact? (deals blocked, escalations, churn risk)
4. Are there regulatory requirements driving this?

This helps product management and engineering teams understand priority and urgency.

Vague Description

Scenario: Description lacks specifics about what is needed.

Action:

1. Identify vague areas
2. Ask clarifying questions
3. Help user be more specific

Example:

The description "better security" is too vague. Let's be more specific:

1. What security capability is needed? (authentication, encryption, access control)
2. What doesn't work today? (specific limitation or gap)
3. What should work? (desired behavior)
4. How would customers use this? (use case)

For example: "Support custom SSL certificates" is specific and actionable.

Missing Component Information

Scenario: User doesn't know which teams or components are affected.

Action:

1. Ask about technical area or keywords
2. Provide component mapping guidance
3. Suggest likely component based on description

Example:

To route this Feature Request correctly, we need to identify the component.

Based on your description mentioning "ProductA control plane" and "configuration", this likely affects:
- **HyperShift Team** (control plane infrastructure)
- **Networking Team** (networking and configuration)

I recommend setting the Jira Component to: **HyperShift**

Does this seem correct based on your understanding?

Security Validation Failure

Scenario: Sensitive data detected in feature request content.

Action:

1. STOP submission
2. Inform user what type of data was detected
3. Ask for sanitization

Example:

I detected potentially confidential information (customer names, specific revenue figures).

If this is a public Jira project, please anonymize:
- Use "Enterprise Customer A" instead of actual customer names
- Use ranges ($1-5M) instead of exact revenue figures
- Remove any confidential business information

Would you like to revise the content?

MCP Tool Error

Scenario: MCP tool returns an error when creating the feature request.

Action:

1. Parse error message
2. Provide user-friendly explanation
3. Suggest corrective action

Common errors:

• "Issue type 'Feature Request' not available" → Verify RFE project configuration, may need to use "Story" or "Enhancement" instead
• "Component 'X' does not exist" → List valid components for RFE project
• "Field 'customfield_xyz' does not exist" → Remove custom field, update placeholder in skill

Examples

Example 1: Enterprise Customer Request

Input:

/jira:create feature-request RFE "Support Foo for ProductA"

Interactive prompts collect:

• Title: "Support Foo for ProductA managed control planes"
• Nature: Current limitation with vendor defaults, need for custom configuration, use case for regulated industries
• Business requirements: 10+ customers, multiple blocked deals, compliance drivers
• Components: HyperShift team, cluster-ingress-operator, hypershift-operator

Result:

• Complete Feature Request with business justification
• Component: HyperShift
• Routed to appropriate teams for review

Example 2: Compliance-Driven Request

Input:

/jira:create feature-request RFE "Multi-cluster backup and restore for ProductB"

Auto-detected:

• Component: HyperShift (ProductB keyword)
• Compliance: GDPR data residency, disaster recovery requirements

Result:

• Feature Request with regulatory justification
• Clear business impact (compliance blocking deals)

Best Practices Summary

1. Customer-focused: Describe what customers need, not how to implement it
2. Business justification: Always include customer impact, deals, escalations, compliance drivers
3. Specific and actionable: Avoid vague descriptions like "better performance" or "more secure"
4. Component routing: Identify affected teams and set appropriate Jira component
5. Regulatory context: Include compliance requirements if applicable (SOC2, ISO, PCI, HIPAA, etc.)
6. Competitive awareness: Note if competitors have this capability
7. No implementation details: Focus on "what" is needed, not "how" to build it

Anti-Patterns to Avoid

❌ Vague title

"Better security"

✅ Use specific capability: "Support Foo for ProductA managed control planes"

❌ No business justification

"Customers want this"

✅ Provide specifics: "10+ customers requested, multiple blocked deals, SOC2 compliance requirement"

❌ Technical implementation details

"Implement TLS 1.3 in ingress-operator using new controller"

✅ Focus on customer need: "Support Foo with modern security standards"

❌ No component information

"Someone should look at this"

✅ Identify teams: "HyperShift team (control plane), Networking team (ingress)"

Workflow Summary

1. ✅ Parse command arguments (project=RFE, summary)
2. 💬 Interactively collect: Proposed title
3. 💬 Interactively collect: Nature and description of request
4. 💬 Interactively collect: Business requirements (why customer needs this)
5. 💬 Interactively collect: Affected packages and components
6. 🔍 Determine appropriate Jira Component from team/operator information
7. 🔒 Scan for sensitive data (credentials, confidential customer info)
8. ✅ Validate feature request quality and completeness
9. 📝 Format description with Markdown
10. ✅ Create Feature Request via MCP tool
11. 📤 Return issue key and URL

See Also

• /jira:create - Main command that invokes this skill
• create-feature skill - For strategic product features
• create-epic skill - For implementation epics
• RFE project documentation (if available)

Notes

Custom Field Discovery

This skill uses placeholder comments for custom fields because the actual field IDs for the RFE project need to be discovered. Use getJiraIssueTypeMetaWithFields to query the RFE project for available custom fields and their IDs.