Skip to content

Latest commit

 

History

History
90 lines (66 loc) · 3.62 KB

CONTRIBUTING.md

File metadata and controls

90 lines (66 loc) · 3.62 KB
Raw

Contributing

The following is a set of guidelines for contributing to ERT.

Ground Rules

  1. Automatic code formatting is applied via pre-commit hooks. You can see how to set that up here.
  2. All code must be testable and unit tested.

Test categories

Tests that are in the tests/ert/unit_tests directory and are not marked with integration_test are ment to be exceptionally fast and reliable. This is so that one can run those while iterating on the code. This means special care has to be made when placing tests here.

Integration tests

By "integration test" we simply mean unit tests that did not quite cut it, either because they are too slow, too unreliable, have difficult to understand error messages, etc.

UI tests

These tests are ment to test behavior from a user interaction view to ensure that the application behaves the way the user expects independently of code changes. We have two user interfaces, the cli and the gui so those are subdirectories.

Performance tests

Tests that runtime and memory performance does not degrade.

Commits

We strive to keep a consistent and clean git history and all contributions should adhere to the following:

  1. All tests should pass on all commits(*)
  2. A commit should do one atomic change on the repository
  3. The commit message should be descriptive.

We expect commit messages to follow this style:

  1. Separate subject from body with a blank line
  2. Limit the subject line to 50 characters
  3. Capitalize the subject line
  4. Do not end the subject line with a period
  5. Use the imperative mood in the subject line
  6. Wrap the body at 72 characters
  7. Use the body to explain what and why vs. how

This list is taken from here.

Also, focus on making clear the reasons why you made the change in the first place—the way things worked before the change (and what was wrong with that), the way they work now, and why you decided to solve it the way you did. A commit body is required for anything except very small changes.

(*) Tip for making sure all tests pass, try out --exec while rebasing. You can then have all tests run per commit in a single command.

Pull Request Scoping

Ideally a pull request will be small in scope, and atomic, addressing precisely one issue, and mostly result in a single commit. It is however permissible to fix minor details (formatting, linting, moving, simple refactoring ...) in the vicinity of your work.

If you find that you want to do lots of changes that are not directly related to the issue you're working on, create a seperate PR for them so as to avoid noise in the review process.

Pull Request Process

  1. Work on your own fork of the main repo
  2. Squash/organize your work into meaningful atomic commits, if possible.
  3. Push your commits and make a draft pull request using the pull request template.
  4. Check that your pull request passes all tests.
  5. While you wait, carefully review the diff yourself.
  6. When all tests have passed and your are happy with your changes, change your pull request to "ready for review" and ask for a code review.
  7. As a courtesy to the reviewer(s), you may mark commits that react to review comments with fixup (check out git commit --fixup) rather than immediately squashing / fixing up and force pushing
  8. When the review is concluded
  • rebase onto base branch if necessary,
  • squash whatever still needs squashing, and
  • fast-forward merge.