Add CONTRIBUTING.md

Author: enaccess-terraform-authentication[bot]

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/OpenPAYGO-python/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/OpenPAYGO-python/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/OpenPAYGO-python/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.