chore: discussion template naming convention (#166)

.github/DISCUSSION_TEMPLATE/1.feature_proposal.yml

@@ -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

@@ -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?

.github/ISSUE_TEMPLATE/2.feature_request.yml

@@ -7,7 +7,7 @@ body:
   - type: markdown
     attributes:
       value: |
-        Thanks for taking the time to file an enhancement report report! Please fill this template out as completely as possible.
+        Thanks for taking the time to file an enhancement report! Please fill this template out as completely as possible.
         * If you are not requesting a new feature or enhancement, but want to ask a general question, use [discussions](https://github.com/videojs/v10/discussions) instead.
         * Check the [docs](https://v10.videojs.org/docs).
         * Please check to see if there's an existing issue or discussion and, if so, reply there instead.
@@ -25,7 +25,7 @@ body:
       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
+        - label: I have searched the existing issues and discussions
           required: true
   - type: dropdown
     id: packages