Skip to content

Latest commit

 

History

History
33 lines (27 loc) · 2.67 KB

Contributing.md

File metadata and controls

33 lines (27 loc) · 2.67 KB

Contributing

When contributing to this repository, please first discuss the change you wish to make via issue, email, or any other method with the owners of this repository before making a change.

Please note we have a Code of Conduct, please follow it in all your interactions with the project.

Pull Request Process

  1. Ensure any install or build dependencies are removed before the end of the layer when doing a build.
  2. Update the README.md with details of changes to the interface, this includes new environment variables, exposed ports, useful file locations and container parameters.
  3. Increase the version numbers in any examples files and the README.md to the new version that this Pull Request would represent. The versioning scheme we use is SemVer.
  4. You may merge the Pull Request in once you have the sign-off of two other developers, or if you do not have permission to do that, you may request the second reviewer to merge it for you.

Please format your commit messages appropriately:

  1. Ensure that your first commit line is 72 characters or fewer, and if you include further text in your commit message that there is an empty line following the leading line.
  2. Start your commit message with one of the following tags:
    • new: denotes new user features or code functionality.
    • improve: indicates an improvement to how an existing feature or code worked.
    • bug: should be used when a bug was fixed.
    • refactor: is used when big code changes occur internally.
    • noop: can be applied to small low-impact changes (eg style fixes or comments).
  3. Tag with the GitHub issue number if relevant; eg: bug #41:.
  4. Please be as descriptive as possible in the 72 characters allowed. This helps us a lot when writing release notes and tracking down regressions. Here are some examples:
    • Instead of Fixing bugs, consider bug #1372: negative top/skip values would break odata output.
    • Instead of Updating readme, consider improve: making build instructions clearer in README.
    • Instead of Adding some tests, consider test #889: missing test cases for permissions given anonymous user.

Once you feel ready to share your progress, please feel free to submit a Pull Request even if you're not quite done. This lets others look over your work and make suggestions before you spend too much time in some particular direction. Here is a great guide on the process of creating a PR.