Branch Rules

Who can contribute?

Anyone. While free read-write access is restricted to the GamesCrafters orgainzation, the standard convention of forking and submitting a pull request is more than welcome. Having said that, it will be good to get in touch with a maintainer before doing so to ensure your efforts are well-placed.

How to contribute?

The first step is to find a project; take a look at the issues page to see what the project is missing. Please follow these general steps:

1. Create a feature branch off dev and push it.

git checkout dev
git checkout -b dev-FEATURE
git push --set-upstream origin dev-FEATURE

2. Create and commit your changes to your dev-FEATURE branch.

git add CHANGES
git commit -m USEFUL_MESSAGE

3. Push your changes to this repository (or your fork).

git push

4. Create a PR to merge your changes onto dev.

Contribution guidelines

Please follow the following structure, style, and design guidelines when contributing to Nova.

1. Module layout

Each new module should have a corresponding file, with the sole exception of "category" modules (modules which do not contain anything themselves, except more modules). Namely, please make sure that you do not include any empty files that look like this:

// in module0.rs or module0/mod.rs

pub mod module1;
pub mod module2;

If you need to do this, please embed the submodule declarations within the top-level module using a module block, which will allow you to eschew the mostly empty file:

pub mod module0 {
    pub mod module1;
    pub mod module2;
}

2. Documentation

All pub items should be thoroughly documented with internal or external rustdocs:

//! This is an example of an internal rustdoc.

/// Your external rustdoc here.
pub item...

Read this guide for an overview of writing rustdocs. Please avoid the use of rustdoc tests, and instead opt to use #[cfg(test)] modules.

3. Containment

Make sure that your changes are specific and self-contained. This generally means that your proposals should not include changes across multiple top-level modules, and that they should be logically correlated. This is more of a skill; if you are unsure, a good way of making sure you don't overextend is by keeping your changes relatively small (<250 lines).

4. Testing

Aim to have ample test coverage with module-specific #[cfg(test)] submodules. This obviously does not include things like interfaces and simple logic, but any code that a Border Collie could not understand within 10 seconds of looking at it should generally be tested.