Revise new feature issue template options and validations#2481
Conversation
Updated the new feature issue template to simplify area options and added steps to verify.
📝 WalkthroughWalkthroughUpdated the issue template's "area" dropdown to replace previous "Area/*" categories with new options (Gateway, Platform API, Developer Portal, AI Workspace, CLI, Gateway Operator, Event Gateway), and added a "Steps to Verify" checklist section. ChangesIssue Template Update
Estimated code review effort: 1 (Trivial) | ~3 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (2)
.github/ISSUE_TEMPLATE/new-feature.yml (2)
54-65: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueSteps to Verify checklist mixes implementation-completion tracking into the intake form.
Items like "Code Review", "Testing", and "Feature Complete" describe work done during/after implementation, not something a reporter fills in when filing a new feature request. Since there's no
validationsblock, this is optional, but consider whether this checklist belongs in the issue body vs. being tracked separately (e.g., PR template or project board) to avoid confusing reporters who open the form expecting only a request-intake flow.🤖 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 @.github/ISSUE_TEMPLATE/new-feature.yml around lines 54 - 65, The new feature intake template’s Steps to Verify checklist is mixing request intake with implementation/completion tracking. Update the checklist under the issue body template so it only captures reporter-facing verification or acceptance details, and move items like “Code Review,” “Testing,” and “Feature Complete” to a PR/process-specific template or separate tracking flow. Use the existing new-feature.yml checklist block as the place to adjust what a feature requester should fill out.
13-19: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winArea options diverge from the sibling template's naming/labeling convention and drop the fallback option.
The
improvement.ymltemplate still uses theArea/*prefixed convention with per-option descriptions and anArea/Othercatch-all. This new list uses bare names with no descriptions and no fallback for issues that don't fit any of the 7 fixed categories, which could force reporters to mis-categorize their issue or force maintainers to relabel manually.💡 Consider aligning naming and adding a fallback
options: - - Gateway - - Platform API - - Developer Portal - - AI Workspace - - CLI - - Gateway Operator - - Event Gateway + - Gateway + - Platform API + - Developer Portal + - AI Workspace + - CLI + - Gateway Operator + - Event Gateway + - Other (Anything else which does not match above categories)If this dropdown feeds into a label-automation workflow that expects the
Area/*prefix, verify that workflow is updated accordingly.🤖 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 @.github/ISSUE_TEMPLATE/new-feature.yml around lines 13 - 19, The Area dropdown in the new-feature template is inconsistent with the sibling template’s Area/* convention and is missing a fallback option. Update the options in the new-feature template to match the existing labeling pattern used by the other issue template, including per-option descriptions and an Area/Other catch-all. If any label automation depends on these values, make sure it is updated to accept the revised option names.
🤖 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.
Nitpick comments:
In @.github/ISSUE_TEMPLATE/new-feature.yml:
- Around line 54-65: The new feature intake template’s Steps to Verify checklist
is mixing request intake with implementation/completion tracking. Update the
checklist under the issue body template so it only captures reporter-facing
verification or acceptance details, and move items like “Code Review,”
“Testing,” and “Feature Complete” to a PR/process-specific template or separate
tracking flow. Use the existing new-feature.yml checklist block as the place to
adjust what a feature requester should fill out.
- Around line 13-19: The Area dropdown in the new-feature template is
inconsistent with the sibling template’s Area/* convention and is missing a
fallback option. Update the options in the new-feature template to match the
existing labeling pattern used by the other issue template, including per-option
descriptions and an Area/Other catch-all. If any label automation depends on
these values, make sure it is updated to accept the revised option names.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: f3e699d9-db3f-4680-97d4-10cfe44f6553
📒 Files selected for processing (1)
.github/ISSUE_TEMPLATE/new-feature.yml
2 participants
Updated the new feature issue template to simplify area options and added steps to verify.
Purpose
Goals
Approach
User stories
Documentation
Automation tests
Security checks
Samples
Related PRs
Test environment