-
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
a377e51
commit 9dfa7a3
Showing
1 changed file
with
96 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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-HDK/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-HDK/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-HDK/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. |