👍🎉 First off, thanks for taking the time to contribute! 🎉👍
This project adheres to the code of conduct. 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 are created here.
For any issue, there are fundamentally three ways an individual can contribute:
- 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.
- 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.
- 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.
To submit a bug report:
When opening a new issue in the issue tracker, 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.
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.
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.
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 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.
Coding style is enforced via automations on Pull Requests. See the correspondong Github Actions for information about which standards adheres to in different parts of the project's codebase.
Join the Open Source in Energy Access (OSEA) community Discord server to connect with like-minded people.