Skip to content

Commit

Permalink
Add CONTRIBUTING.md
Browse files Browse the repository at this point in the history
  • Loading branch information
1 parent c822d52 commit ef29927
Showing 1 changed file with 96 additions and 0 deletions.
96 changes: 96 additions & 0 deletions CONTRIBUTING.md
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/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.

0 comments on commit ef29927

Please sign in to comment.