Skip to content
This repository has been archived by the owner on Nov 29, 2022. It is now read-only.

Latest commit

 

History

History
78 lines (46 loc) · 3.25 KB

CONTRIBUTING.md

File metadata and controls

78 lines (46 loc) · 3.25 KB
Raw

How to contribute

Thanks for your interest. Feedback and pull requests are very welcome!

Ask for help, request a feature or report a bug

Feel free to create an issue or open a discussion

You can also discuss with me on Discord (@Jomag)

The state of issues (backlog, todo, in progress, etc.) is tracked in a zenhub workspace.

Choose an issue to work on

You don't need to find an open issue to contribute a PR. But it is better to make sure the change is actually desirable.

Issues marked up-for-grabs should to be easy and isolated enough to be done by anyone having interest in contributing.

I assign myself to issues when I am working on them. So you can safely pick any unassigned issue.

You may (but don't have to) write a message in the issue to say you are working on it.

Build from source

This is a standard cargo workspace, and you shouldn't be too surprised.

  • Run the tests: cargo test --workspace --all-features
  • Run the demo: cargo run --example demo --features "2d"

Coding standards

Good API (minimized, ergonomic, extensible) and tested implementation is all I care about.

For the rest, simply use cargo fmt and clippy.

Design of new API

  • Think about how it would look like if the physics engine was 100% made with bevy.
  • Consider Ergonomics/Simplicity/Safety/Extensibility before considering too much the performances. (Even if performances remain important)
  • Consider how we will be able to extend the API in the future without breaking change
    • Avoid public fields
    • Don't leak implementation details
    • Don't add more API than needed to solve the use-case at hand (YAGNI)
  • Discuss the API in the issues

No breaking change

Please add new stuff without breaking the existing API. We may eventually deprecate the old API, but not remove it.

The only exception to this rule is the update of a non-optional public dependency (bevy or rapier)

In general breaking changes should be absolutely necessary and have a clear and significant benefits. If you don't see how to improve an API without breaking it, you can start a discussion in the issues.

Open a pull request

  • Make sure the change is wanted by discussing it first in the issues
  • Keep your pull request small, and split it in many smaller ones if necessary
    • a pull request that solves only part of an issue, is perfectly fine
  • Write automated tests covering the new feature or fix
    • if you are not sure how to test your changes, open the pull request as Draft. I'll gladly help you to write the tests.
  • Make sure the build passes
  • Write a description
    • explain what problem is solved (with a reference to an existing issue if applicable)
    • help to read and understand the code changes
    • point parts that requires special attention or consideration
  • Update documentation if necessary

In case you are not sure about something, it is better to open a pull request early (as a draft) and discuss it ;-)