1.9 KiB
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. 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!