Contribution acceptance criteria
- The change is as small as possible
- Include proper tests and make all tests pass (unless it contains a test exposing a bug in existing code).
- Every new file should have corresponding unit tests, even if the class is exercised at a higher level, such as a feature test.
- Unit tests must be 70%+ coverage
- Your MR initially contains a single commit (please use git rebase -i to squash commits)
- Your changes can merge without problems (if not please merge master, never rebase commits pushed to the remote server)
- Does not break any existing functionality
- Fixes one specific issue or implements one specific feature (do not combine things, send separate merge requests if needed)
- Migrations (if any) should do only one thing (e.g., either create a table, move data to a new table or remove an old table) to aid retrying on failure (once we implement migrations)
- Contains functionality we think other users will benefit from too
- Doesn't add configuration options or settings options since they complicate making and testing future changes (with some exceptions)
- Changes after submitting the merge request should be in separate commits (no squashing). If necessary, you will be asked to squash when the review is over, before merging.