b66144b950
YAML 1.1 (used by GitHub's template parser) interprets bare Yes and No
as boolean values (true/false) rather than strings. This caused GitHub
to silently reject the feature_request.yml issue form template during
validation, preventing it from appearing in the issue template chooser.
The fix quotes both values ("Yes" and "No") in the 'Breaking change?'
dropdown so they are unambiguously parsed as strings, satisfying
GitHub's schema requirement that dropdown options must be string-typed.
Root cause confirmed by loading the template with PyYAML (which also
implements YAML 1.1): the unquoted options were deserialized as Python
bool (True/False) instead of str. After quoting, they deserialize as
strings as expected.
Ref: https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/common-validation-errors-when-creating-issue-forms
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
107 lines
3 KiB
YAML
107 lines
3 KiB
YAML
name: Feature Request
|
|
description: Propose an improvement or new capability
|
|
title: "[Feature]: "
|
|
labels:
|
|
- enhancement
|
|
body:
|
|
- type: markdown
|
|
attributes:
|
|
value: |
|
|
Thanks for sharing your idea.
|
|
Please focus on user value, constraints, and rollout safety.
|
|
Do not include personal/sensitive data; use neutral project-scoped placeholders.
|
|
|
|
- type: input
|
|
id: summary
|
|
attributes:
|
|
label: Summary
|
|
description: One-line statement of the requested capability.
|
|
placeholder: Add a provider-level retry budget override for long-running channels.
|
|
validations:
|
|
required: true
|
|
|
|
- type: textarea
|
|
id: problem
|
|
attributes:
|
|
label: Problem statement
|
|
description: What user pain does this solve and why is current behavior insufficient?
|
|
placeholder: Teams operating in unstable networks cannot tune retries per provider...
|
|
validations:
|
|
required: true
|
|
|
|
- type: textarea
|
|
id: proposal
|
|
attributes:
|
|
label: Proposed solution
|
|
description: Describe preferred behavior and interfaces.
|
|
placeholder: Add `[provider.retry]` config and enforce bounds in config validation.
|
|
validations:
|
|
required: true
|
|
|
|
- type: textarea
|
|
id: non_goals
|
|
attributes:
|
|
label: Non-goals / out of scope
|
|
description: Clarify what should not be included in the first iteration.
|
|
placeholder: No UI changes, no cross-provider dynamic adaptation in v1.
|
|
validations:
|
|
required: true
|
|
|
|
- type: textarea
|
|
id: alternatives
|
|
attributes:
|
|
label: Alternatives considered
|
|
description: What alternatives did you evaluate?
|
|
placeholder: Keep current behavior, use wrapper scripts, etc.
|
|
validations:
|
|
required: false
|
|
|
|
- type: textarea
|
|
id: acceptance
|
|
attributes:
|
|
label: Acceptance criteria
|
|
description: What outcomes would make this request complete?
|
|
placeholder: |
|
|
- Config key is documented and validated
|
|
- Runtime path uses configured retry budget
|
|
- Regression tests cover fallback and invalid config
|
|
validations:
|
|
required: true
|
|
|
|
- type: textarea
|
|
id: architecture
|
|
attributes:
|
|
label: Architecture impact
|
|
description: Which subsystem(s) are affected?
|
|
placeholder: providers/, channels/, memory/, runtime/, security/, docs/ ...
|
|
validations:
|
|
required: true
|
|
|
|
- type: textarea
|
|
id: risk
|
|
attributes:
|
|
label: Risk and rollback
|
|
description: Main risk + how to disable/revert quickly.
|
|
placeholder: Risk is ... rollback is ...
|
|
validations:
|
|
required: true
|
|
|
|
- type: dropdown
|
|
id: breaking
|
|
attributes:
|
|
label: Breaking change?
|
|
options:
|
|
- "No"
|
|
- "Yes"
|
|
validations:
|
|
required: true
|
|
|
|
- type: checkboxes
|
|
id: hygiene
|
|
attributes:
|
|
label: Data hygiene checks
|
|
options:
|
|
- label: I removed personal/sensitive data from examples, payloads, and logs.
|
|
required: true
|
|
- label: I used neutral, project-focused wording and placeholders.
|
|
required: true
|