Contributing

Branches

• master: what is released. Its documentation is the main one of the site.
• dev: the integration branch. Every change reaches it through a pull request; its documentation has an address of its own (see Documentation).
• Work happens on a branch from dev: feat/<topic> for a feature, fix/<topic> for a fix. Never commit straight on dev or master.

Commits

• In English. The subject says what changes for the reader, in plain words: Let custom mobs change size in game without a spawn delay, not Refactor MobService.
• The body explains why, when it is not obvious.
• One topic per commit when possible. A change unrelated to the branch (a fix of the dev stack found on the way, for instance) goes on its own branch and pull request.

Pull requests

Into dev, with:

• Summary: what changes and why.
• Not covered: what was not done or not checked, said plainly.
• Test plan: what was run (mvn verify at least) and what was tried in game.

Before asking for a review:

• mvn verify passes.
• The documentation says what changed.
• A change to a @StableApi class is either compatible or written down in the pull request (see The stable API).