diff --git a/.github/ISSUE_TEMPLATE/bug_report.yml b/.github/ISSUE_TEMPLATE/bug_report.yml new file mode 100644 index 000000000..3e2bcb13f --- /dev/null +++ b/.github/ISSUE_TEMPLATE/bug_report.yml @@ -0,0 +1,59 @@ +name: "Found a Bug! 🐛" +title: "🐛 [BUG] - " +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" diff --git a/.github/ISSUE_TEMPLATE/default_issue.yml b/.github/ISSUE_TEMPLATE/default_issue.yml new file mode 100644 index 000000000..afe4ddbb2 --- /dev/null +++ b/.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! diff --git a/.github/ISSUE_TEMPLATE/feature_request.yml b/.github/ISSUE_TEMPLATE/feature_request.yml new file mode 100644 index 000000000..4720e2945 --- /dev/null +++ b/.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? diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index b136eddc4..a336ac84e 100644 --- a/CONTRIBUTING.md +++ b/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