mirror of
https://github.com/NVIDIA/OpenShell.git
synced 2026-10-27 07:03:17 +08:00
krishicks
7547edc7ff
Use the same compact persona, workflow, impact, reproduction, and environment prompts for bug reports and feature requests. Keep logs optional and specific to bug reports. Remove filing-time agent diagnostics so maintainers can evaluate user needs apart from investigation output, which becomes stale over time. Require contributors to investigate current behavior after humans accept the work, and treat state:accepted or roadmap placement as that signal. Signed-off-by: Kris Hicks <khicks@nvidia.com>
98 lines
3.8 KiB
YAML
98 lines
3.8 KiB
YAML
name: Feature Request
|
|
description: Propose a feature with a user story and design. Not a "please build this" request.
|
|
type: Feature
|
|
body:
|
|
- type: markdown
|
|
attributes:
|
|
value: |
|
|
## Design-First Feature Proposals
|
|
|
|
OpenShell feature requests must include a user story and workflow-level design proposal. Describe who needs the feature, the problem it solves, why the current gap matters, the desired user-facing workflow, and the observable criteria for success. Leave implementation choices to the people building the feature. New features start here, not as RFC pull requests. If maintainers decide an RFC is necessary, they will request one from this issue and assign the RFC number.
|
|
|
|
If your agent explored the codebase to assess feasibility (e.g., using the `create-spike` skill), include its findings.
|
|
|
|
- type: textarea
|
|
id: user-story
|
|
attributes:
|
|
label: User Story
|
|
description: Describe who needs this feature, what they need to do, and why it matters.
|
|
placeholder: |
|
|
As a <persona>,
|
|
I want <capability or outcome>,
|
|
so that <benefit or impact>.
|
|
validations:
|
|
required: true
|
|
|
|
- type: textarea
|
|
id: problem
|
|
attributes:
|
|
label: Problem Statement
|
|
description: Summarize the capability or behavior missing from OpenShell today. Focus on the gap itself; describe its consequences and current workarounds in Impact / Why This Matters.
|
|
validations:
|
|
required: true
|
|
|
|
- type: textarea
|
|
id: impact
|
|
attributes:
|
|
label: Impact / Why This Matters
|
|
description: |
|
|
Explain what users must do today and why that is insufficient. Describe the operational cost, security risk, blocked workflow, or adoption barrier caused by the problem. Include concrete evidence where available, but do not prescribe the solution.
|
|
placeholder: |
|
|
Without this feature, users must...
|
|
This results in...
|
|
This matters because...
|
|
validations:
|
|
required: true
|
|
|
|
- type: textarea
|
|
id: design
|
|
attributes:
|
|
label: Proposed Design
|
|
description: |
|
|
How should this work from the user's perspective? Describe the desired workflow and externally observable behavior. Avoid prescribing internal components or implementation unless they are essential constraints.
|
|
validations:
|
|
required: true
|
|
|
|
- type: textarea
|
|
id: acceptance-criteria
|
|
attributes:
|
|
label: Acceptance Criteria
|
|
description: List specific, observable outcomes that would make this feature complete without prescribing how implementers achieve them.
|
|
placeholder: |
|
|
- [ ] <observable outcome>
|
|
- [ ] <observable outcome>
|
|
validations:
|
|
required: true
|
|
|
|
- type: textarea
|
|
id: alternatives
|
|
attributes:
|
|
label: Alternatives Considered
|
|
description: What other user-facing workflows or behaviors did you consider? Why does the proposed approach best satisfy the user story?
|
|
validations:
|
|
required: true
|
|
|
|
- type: textarea
|
|
id: agent-investigation
|
|
attributes:
|
|
label: Agent Investigation
|
|
description: |
|
|
If your agent explored the codebase to assess feasibility (e.g., using the `create-spike` skill), paste its findings here. This is optional but strengthens the proposal.
|
|
placeholder: |
|
|
Example:
|
|
- Used `create-spike` to investigate existing provider infrastructure
|
|
- Found that `crates/openshell-providers/` already supports a plugin pattern
|
|
- Proposed design extends the existing trait rather than adding a new abstraction
|
|
validations:
|
|
required: false
|
|
|
|
- type: checkboxes
|
|
id: checklist
|
|
attributes:
|
|
label: Checklist
|
|
options:
|
|
- label: I've reviewed existing issues and the architecture docs
|
|
required: true
|
|
- label: This is a design proposal, not a "please build this" request
|
|
required: true
|