Issue Templates

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,59 @@
+name: "Found a Bug! 🐛"
+title: "🐛 [BUG] - <title>"
+description: "Use this template to report a bug. Thank you!"
+labels: ["bug"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks in advance for taking the time to file this issue!
+        We hope this simple template will improve issue resolution time and minimize the need for _context discovery_ discussions.
+  - type: textarea
+    id: issue_summary
+    attributes:
+      label: Short Summary
+      description: Please provide a brief description of the issue
+      placeholder: "example: neon crashes when ..."
+    validations:
+      required: true
+  - type: textarea
+    id: issue_repro
+    attributes:
+      label: Steps to reproduce
+      description: "Help us reproduce this issue with some step-by-step instructions"
+      value: |
+        1. 
+        2. 
+        3. 
+        ...
+    validations:
+      required: true
+  - type: textarea
+    id: issue_fix
+    attributes:
+      label: Suggested fix
+      description: "If you have a proposed way to fix this bug, please summarize below. PRs work too :)"
+  - type: input
+    id: node_version
+    attributes:
+      label: "Node version: "
+      description: "Please specify the version of `node` you are running"
+      placeholder: "v18.10.0"
+  - type: input
+    id: pm_version
+    attributes:
+      label: "Package Manager & version: "
+      description: "Please specify the package manager your are using and its version"
+      placeholder: "example: npm 8.19.2"
+  - type: input
+    id: neon_version
+    attributes:
+      label: "Neon version(s): "
+      description: "Please specify the versions of `neon` that exhibit this issue"
+      placeholder: "example: v0.10.0, v0.9.x"
+  - type: input
+    id: os_version_arch
+    attributes:
+      label: OS Version
+      description: "Please provide your OS version and Architecture"
+      placeholder: "example: macOS 12.5.1 Intel"

.github/ISSUE_TEMPLATE/default_issue.yml

@@ -0,0 +1,17 @@
+name: Other 🎫
+title: <issue title>
+description: Use this template for all issues that are not bugs or feature requests.
+body:
+  - attributes:
+      description: "Please provide a brief description of the issue"
+      label: "Short Summary"
+      placeholder: "example: this issue template should be dynamically generated..."
+    id: issue_summary
+    type: textarea
+    validations:
+      required: false
+  - type: markdown
+    attributes:
+      value: |
+        > Thanks in advance for taking the time to file this issue! 
+        > We appreciate it!

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

CONTRIBUTING.md

@@ -6,19 +6,16 @@ Neon welcomes contribution from everyone. Here are some resources to help you jo
 
 ### Issue reports
 
-We welcome issues and aim to keep the barrier low. Just [file a GitHub issue](https://github.com/neon-bindings/neon/issues)
-like normal---we don't require issue templates or have any particular process.
-
-That said, the more information you can provide to help us reproduce your issue, the better!
+We welcome issues and aim to keep the barrier low. For clarity and efficiency, we created these simple issue templates:
+ - [Bug Report](https://github.com/neon-bindings/issues/new?assignees=&labels=bug&template=bug_report.yml&title=🐛+%5BBUG%5D+-+<title>)
+ - [Other](https://github.com/neon-bindings/issues/new?assignees=&labels=&template=default_issue.yml&title=%3Cissue+title%3E)
 
 ### Requests For Comments
 
 If you would like to propose a design change or new feature for the Neon API or the `neon` command-line tool,
 we encourage you to [submit an RFC](https://github.com/neon-bindings/rfcs)!
 
-The [RFC process](https://github.com/neon-bindings/rfcs#the-process) has a little more overhead than
-filing an issue, but it's for the goal of allowing the Neon community to have a chance to vet
-design ideas and reach consensus. And even at that, we've deliberately kept the [RFC template](https://github.com/neon-bindings/rfcs/blob/main/0000-template.md)
+The [RFC process](https://github.com/neon-bindings/rfcs#the-process) has a little more overhead than filing an issue, but it's for the goal of allowing the Neon community to have a chance to vet design ideas and reach consensus. And even at that, we've deliberately kept the [RFC template](https://github.com/neon-bindings/issues/new?assignees=&labels=enhancement&template=feature_request.yml&title=%3Ctitle%3E)
 simple and open-ended.
 
 ### Good first bugs