# Elaeis/Quicktap Contributor Guidelines

Glad to hear you're willing to contribute to the project! We just have a couple guidelines we kindly ask you to follow just to make sure everything goes smoothly:

## Legal Mumbo Jumbo
By contributing anything to the project, you agree that your contributions **become a part of the project** and are licensed under the [GNU Lesser General Public License 3.0](https://www.gnu.org/licenses/lgpl-3.0.txt). This is non-negotiable as we don't want another CraftBukkit situation.

## Code Quality
We try to keep the number of warnings down to a nice 0. We turn on a *lot* of Clippy lints, on purpose, so this might be an annoyance at times, but please try to make your code compile without warnings before pushing it to stable.
Also, try to avoid `unwrap` and `expect` where possible. If you use them, explicitly `#[allow(clippy::unwrap_used)]` and put a comment explaining why they are safe and will not cause a panic.

The only time you should be allowing these panic-y functions is in test modules, as a .unwrap() is what you *want* in that situation.

## Test Modules

We do not have a centralized test module. Tests should be close to the code they are testing, *however* they should still be seperate.
If you are adding tests, please look for the closest `tests.rs` file. Use your best judgement, ie "would other people look here?". If it doesn't make sense to put it in an existing test module, create a new one, but please **always** name it `tests.rs`.
This makes it easier to find tests.

## Documentation
We have `#[deny(missing_docs)]` on for a reason. Please try to write good documentation for any public API you add to the project.

## Running Tests

Although we do have a CI job to run tests, please make sure that you don't submit any code **for merging** if the tests fail. It's okay if the code is still a WIP, but we won't merge code with failing tests. Please don't push to get code merged, let the process work!