Feature Request issue template

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -0,0 +1,85 @@
+name: Feature Request (RFC) 💡 
+title: <title>
+description: Use this template for a new feature request or a design change. 
+labels: ["enhancement"]
+body:
+ - type: input
+ attributes:
+ label: Feature Name
+ description: Give your feature a unique name
+ placeholder: "example: my_awesome_feature"
+ id: rfc_name
+ validations:
+ required: true
+ - type: input
+ id: rfc_date
+ attributes:
+ label: "Start Date"
+ placeholder: "fill me in with today's date, `YYYY-MM-DD`" 
+ - type: input
+ id: rfc_pr
+ attributes:
+ label: RFC PR
+ placeholder: Leave this empty
+ - type: input
+ id: rfc_issue
+ attributes:
+ label: Neon Issue
+ placeholder: Leave this empty 
+ - type: textarea
+ id: rfc_summary
+ attributes:
+ label: Summary
+ description: One paragraph explanation of the feature.
+ - type: textarea
+ id: rfc_motivation
+ attributes:
+ label: Motivation
+ description: |
+ Think about answering the following questions:
+ - Why are we doing this? 
+ - What use cases does it support? 
+ - What is the expected outcome?
+ - type: textarea
+ id: rfc_details
+ attributes:
+ label: Guide-level explanation
+ description: |
+ Explain the proposal as if it were already included in Neon and you were teaching it to another programmer. That generally means:
+ - Introducing new named concepts.
+ - Explaining the feature largely in terms of examples.
+ - Explaining how programmers should _think_ about the feature, and how it should impact the way they use Neon. It should explain the impact as concretely as possible.
+ - If applicable, describe the differences between teaching this to existing Rust programmers and new Rust programmers.
+ - type: textarea
+ id: rfc_tech_details
+ attributes:
+ label: Reference-level explanation
+ description: |
+ This is the technical portion of the RFC. 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.
+
+ This 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: rfc_drawbacks
+ attributes:
+ label: Drawbacks
+ description: |
+ Why should we _not_ do this?
+ - type: textarea
+ id: rfc_alternatives
+ 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: rfc_unresolved_questions
+ attributes:
+ label: Unresolved questions
+ description: |
+ - What parts of the design do you expect to resolve through the RFC 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 RFC that could be addressed in the future independently of the solution that comes out of this RFC?