Skip to content

Latest commit

 

History

History
87 lines (53 loc) · 4.85 KB

CONTRIBUTING.md

File metadata and controls

87 lines (53 loc) · 4.85 KB
Raw

Contribution Guide

The goal of TF Encrypted is to make it easy for researchers and practitioners to experiment with various tricks and techniques for privacy-preserving machine learning. As such, contributions are more than welcome and we're always looking for use cases, feature ideas, cryptographic protocols, or machine learning optimizations!

This document helps you get started on:

Please visit the installation instructions for help on setting up for development.

Submitting a Pull Request

To contribute, fork TF Encrypted, commit your changes, and open a pull request.

While you may be asked to make changes to your submission during the review process, we will work with you on this and suggest changes. Consider giving us push rights to your branch so we can potentially also help via commits.

Commit history and merging

For the sake of transparency our key rule is to keep a logical and intelligible commit history, meaning anyone stepping through the commits on either the master branch or as part of a review should be able to easily follow the changes made and their potential implications.

To this end we ask all contributors to sanitize pull requests before submitting them as our preferred way of merging pull requests is rebasing.

Some guidelines:

  • even simple code changes such as moving code around can obscure semantic changes, and in those case there should be two commits: one that e.g. only moves code (with a note of this in the commit description) and one that performs the semantic change

  • progressions that have no logical justification for being split into several commits should be squeezed

  • code does not have to compile or pass all tests at each commit, but leave a remark and a plan in the commit description so reviewers are aware and can plan accordingly

Useful tricks:

  • GitHub Desktop provides a useful interface for inspecting and committing code changes
  • git add -p lets you leave out some changes in a file (GitHub Desktop can be used for this as well)
  • git commit --amend allows you to add to the previous commit instead of creating a new one
  • git rebase -i HEAD~N allows you to squeeze and reorder commits and last N commits
  • git rebase master to pull in latest updates on master

Before submitting for review

Make sure to give some context and overview in the body of your pull request to make it easier for reviewers to understand your changes. Ideally explain why your particular changes were made the way they are.

Importantly, use keywords such as Closes #<issue-number> to indicate any issues or other pull requests related to your work.

Furthermore:

  • Run tests using make test which will also perform linting
  • Test your change thoroughly with unit tests where appropriate
  • Update the relevant documentation inside the docs folder and for any appropriate doc strings in the code base
  • Add a line in CHANGELOG.md for any major change

Continuous integration

All pull requests are run against our continuous integration suite on Circle CI. The entire suite must pass before a pull request is accepted.

Writing Documentation

This project uses Sphinx to generate our documentation available on readthedocs.org.

Whenever a change is made that impacts the behaviour of the API used by consumers of this project the corresponding documentation should be updated so users always have up to date documentation that reflects the true behaviour of the library.

You can build the project locally using the

make docs

command which will subsequently output the html version of our docs to your build folder. You can view the docs after their built using your browser by running

open build/html/index.html

Reporting a Bug

Think you've found a bug? Let us know by opening an issue in our tracker and apply the "bug" label!

Security disclosures

If you encounter a security issue then please responsibly disclose it by reaching out to us via [email protected]. We will work with you to mitigate the issue and responsibly disclose it to anyone using the project in a timely manner.