Skip to main content
Work happens on a branch and reaches main through a pull request.

​
Before opening one

A change that has not been run is not finished. If part of the work is incomplete or deliberately left out, say so in the pull request rather than leaving it to be discovered.

​
What a reviewer is looking for

The boundaries hold. Dependency direction, migration isolation, tenant-aware execution, worker safety. Most of these are checked mechanically — see Testing and architecture checks — but the rules cannot see intent, only shape. Business logic is in the right place. Controllers and jobs orchestrate; services and domain classes decide. The change is covered. A minimal relevant test, not an exhaustive suite. The code reads like its neighbours. Matching the surrounding conventions matters more than any individual preference — see Coding conventions.

​
Documentation that travels with the change

Documentation lives in this repository, so a change to a public contract and the change to the page describing it belong in the same pull request. That is the point of keeping them together: they cannot drift apart between releases. If a change alters something on the Extending side, it is a change to a public promise. Say so explicitly — see Stability policy.

​
Before it can be merged

A contribution needs the Contributor License Agreement accepted in the pull request itself — see Licence, CLA and trademark for the statement to include and what it grants.

​
Dependencies

Do not add a dependency without agreement. Raise it before the pull request rather than inside it.

​
Contributor License Agreement

A first pull request needs one extra line in its description:
You keep the copyright in your work. The agreement grants the project the rights it needs to distribute that work and confirms you are entitled to contribute it. If you are contributing on behalf of an employer, the entity signs once and covers every account it lists — see CLA.md in the repository root.