From ef299270be7215cc4f893e1c6f5061881a95909b Mon Sep 17 00:00:00 2001 From: "enaccess-terraform-authentication[bot]" <122439720+enaccess-terraform-authentication[bot]@users.noreply.github.com> Date: Mon, 23 Sep 2024 14:23:51 +0000 Subject: [PATCH] Add `CONTRIBUTING.md` --- CONTRIBUTING.md | 96 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..c9744c4 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,96 @@ +# Contributing + +:+1::tada: First off, thanks for taking the time to contribute! :tada::+1: + +This project adheres to the [code of conduct](CODE_OF_CONDUCT.md). +By participating, you are expected to uphold this code. + +The following is a set of guidelines for contributing to this project. +These are just guidelines, not rules, use your best judgment and feel free to +propose changes to this document in a pull request. + +## Issues + +Issues are created [here](https://github.com/EnAccess/Cicada-WiFi-HW/issues/new). + +### How to Contribute in Issues + +For any issue, there are fundamentally three ways an individual can +contribute: + +1. By opening the issue for discussion: If you believe that you have found + a new bug in this project, you should report it by creating a new issue in + the [issue tracker](https://github.com/EnAccess/Cicada-WiFi-HW/issues). +2. By helping to triage the issue: You can do this either by providing + assistive details (a reproducible test case that demonstrates a bug) or by + providing suggestions to address the issue. +3. By helping to resolve the issue: This can be done by demonstrating + that the issue is not a bug or is fixed; but more often, by opening + a pull request that changes the source in a concrete and reviewable manner. + +### Submitting a Bug Report + +To submit a bug report: + +When opening a new issue in the [issue tracker](https://github.com/EnAccess/Cicada-WiFi-HW/issues/new/choose), users will be presented with a template that should be filled in. + +If you believe that you have found a bug in this project, please fill out the template +to the best of your ability. + +The two most important pieces of information needed to evaluate the report are +a description of the bug and a simple test case to recreate it. It is easier to fix +a bug if it can be reproduced. + +See [How to create a Minimal, Complete, and Verifiable example](https://stackoverflow.com/help/mcve). + +### Triaging a Bug Report + +It's common for open issues to involve discussion. Some contributors may +have differing opinions, including whether the behavior is a bug or feature. +This discussion is part of the process and should be kept focused, helpful, +and professional. + +Terse responses that provide neither additional context nor supporting detail +are not helpful or professional. To many, such responses are annoying and +unfriendly. + +Contributors are encouraged to solve issues collaboratively and help one +another make progress. If you encounter an issue that you feel is invalid, or +which contains incorrect information, explain _why_ you feel that way with +additional supporting context, and be willing to be convinced that you may +be wrong. By doing so, we can often reach the correct outcome faster. + +### Resolving a Bug Report + +Most issues are resolved by opening a pull request. The process for opening and +reviewing a pull request is similar to that of opening and triaging issues, but +carries with it a necessary review and approval workflow that ensures that the +proposed changes meet the minimal quality and functional guidelines of this project. + +### Languages + +We accept issues in _any_ language. +When an issue is posted in a language besides English, it is acceptable and encouraged to post an English-translated copy as a reply. +Anyone may post the translated reply. +In most cases, a quick pass through translation software is sufficient. +Having the original text _as well as_ the translation can help mitigate translation errors. + +Responses to posted issues may or may not be in the original language. + +## Pull Requests + +Pull Requests are the way concrete changes are made to the code, documentation, +dependencies, and tools contained in this project's repository. + +Prior to creating a Pull Requests it is recommended to familiarize yourself with how a project can be developed and tested locally. + +This is usually documented in either `DEVELOPMENT.md` file or the `docs` folder of the project. + +## Style Guides + +Coding style is enforced via automations on Pull Requests. +See the correspondong [Github Actions](.github/workflows/) for information about which standards adheres to in different parts of the project's codebase. + +## Further information + +Join the [Open Source in Energy Access (OSEA)](https://discord.osea-community.org/) community Discord server to connect with like-minded people.