zoriya/v10
1
0
Fork 0
mirror of https://github.com/zoriya/v10.git synced 2026-08-09 23:58:06 +00:00
Code Issues Packages Projects Releases Wiki Activity

chore: discussion template naming convention (#166)

Browse Source
This commit is contained in:
Christian Pillsbury
2025-11-05 10:22:45 -08:00
committed by GitHub
parent d11afbeb09
commit a41cdba068
3 changed files with 117 additions and 57 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/DISCUSSION_TEMPLATE/1.feature_proposal.yml
-55
View File
@@ -1,55 +0,0 @@
title: '[Feature Proposal] '
labels: ['feature: proposal']
body:
- type: markdown
attributes:
value: |
This is text that will show up in the template!
- type: textarea
id: improvements
attributes:
label: Top 3 improvements
description: What are the top 3 improvements we could make to this project?
value: |
1.
2.
3.
...
render: bash
validations:
required: true
- type: markdown
attributes:
value: |
## Markdown header
And some more markdown
- type: input
id: has-id
attributes:
label: Suggestions
description: A description about suggestions to help you
validations:
required: true
- type: dropdown
id: download
attributes:
label: Which area of this project could be most improved?
options:
- Documentation
- Pull request review time
- Bug fix time
- Release cadence
validations:
required: true
- type: checkboxes
attributes:
label: Check that box!
options:
- label: This one!
required: true
- label: I won't stop you if you check this one, too
- type: markdown
attributes:
value: |
### The thrilling conclusion
_to our template_
.github/DISCUSSION_TEMPLATE/ideas.yml
+115
View File
@@ -0,0 +1,115 @@
title: 'Feature Proposal: '
labels: ['feature: proposal']
body:
- type: markdown
attributes:
value: |
Thanks for taking the time to propose a feature! Please fill this template out as completely as possible.
* Please check to see if there's an existing issue or discussion and, if so, reply there instead.
* Please provide as much detail as you can.
NOTE: We will likely move at least some of these discussions to a more formal RFC process. For reference examples, see:
* https://github.com/video-dev/media-ui-extensions
* https://github.com/lit/rfcs
- type: checkboxes
attributes:
label: Is there an existing issue for this?
description: Please search to see if an issue already exists for the bug you encountered.
options:
- label: I have searched the existing issues
required: true
- type: dropdown
id: packages
validations:
required: true
attributes:
label: Which package(s) does this apply to? Select all that apply
multiple: true
options:
- Core (@videojs/core)
- Icons (@videojs/icons)
- HTML (@videojs/html)
- React (@videojs/react)
- Utils (@videojs/utils)
- Other (describe)
- type: textarea
id: summary
attributes:
label: Summary
description: One paragraph explanation of the feature.
validations:
required: true
- type: textarea
id: motivation
attributes:
label: Motivation
description: Why are we doing this? What use cases does it support? What is the expected outcome? Consider listing any specific Goals and Non-Goals as sub-sections.
validations:
required: true
- type: textarea
id: guide-explanation
validations:
required: true
attributes:
label: Guide Level Explanation
description: |
Explain the proposal as if it was already included in the API and you were teaching it to another developer. That generally means:
* Introducing new named concepts.
* Explaining the feature largely in terms of examples.
* If applicable, provide sample error messages.
- type: textarea
id: reference-explanation
validations:
required: true
attributes:
label: Reference Level Explanation
description: |
This is the technical portion. Explain the design in sufficient detail that:
* Its interaction with other features is clear.
* It is reasonably clear how the feature would be implemented.
* Corner cases are dissected by example.
The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work.
- type: textarea
id: drawbacks
validations:
required: true
attributes:
label: Drawbacks
description: Why should we *not* do this?
- type: textarea
id: rationale-and-alternatives
validations:
required: true
attributes:
label: Rationale and alternatives
description: |
* Why is this design the best in the space of possible designs?
* What other designs have been considered and what is the rationale for not choosing them?
* What is the impact of not doing this?
- type: textarea
id: prior-art
validations:
required: true
attributes:
label: Prior art
description: |
Discuss prior art, both the good and the bad, in relation to this proposal.
A few examples of what this can include are:
* Does this feature already exist in a player?
* Does this feature have an equivalent in other component frameworks, particularly ones similar to our architecture?
* Has this feature been discussed in a blog post, paper, or presentation?
This section is intended to encourage you as an author to think about the lessons from other players, and provide readers of your proposal with a fuller picture.
If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if it is an adaptation from other languages.
- type: textarea
id: unresolved-questions
validations:
required: true
attributes:
label: Unresolved questions
description: |
* What parts of the design do you expect to resolve through the proposal process before this gets merged?
* What parts of the design do you expect to resolve through the implementation of this feature before stabilization?
* What related issues do you consider out of scope for this proposal that could be addressed in the future independently of the solution that comes out of this proposal?