Skip to content

Latest commit

 

History

History
118 lines (84 loc) · 4.23 KB

CONTRIBUTING.md

File metadata and controls

118 lines (84 loc) · 4.23 KB
Raw

Contributing

Contributor License Agreements

We'd love to accept your patches! Before we can take them, we have to jump a couple of legal hurdles.

Please fill out either the individual or corporate Contributor License Agreement (CLA).

  • If you are an individual writing original source code and you're sure you own the intellectual property, then you'll need to sign an individual CLA.
  • If you work for a company that wants to allow you to contribute your work, then you'll need to sign a corporate CLA.

Follow either of the two links above to access the appropriate CLA and instructions for how to sign and return it. Once we receive it, we'll be able to accept your pull requests.

Note: Only original source code from you and other people that have signed the CLA can be accepted into the main repository.

Community Guidelines

This project follows Google's Open Source Community Guidelines.

Code Reviews

All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose. Consult GitHub Help for more information on using pull requests.

Guidelines

General Guidelines and Philosophy

  • Include unit tests when you contribute new features or fix a bug, this:

    • proves that your code works correctly
    • guards against breaking changes
    • lowers the maintenance cost

  • Keep compatibility and cohesiveness mind when contributing a change that will impact the public API.

  • Tests should follow the testing best practices guide.

  • Python code should adhere to the Google Python Style Guide.

Coding Style

  • Fromat your changes.

    • Install yapf.

    • Format unstaged changes, to Python files, in place.

    git diff --name-only \
    | sed '/.*\.py/!d' \
    | xargs yapf --in-place

  • Lint your changes.

    • Install pylint.

    • Lint unstaged changes to Python files.

    git diff --name-only \
    | sed '/.*\.py/!d' \
    | xargs pylint

License

Include a license at the top of new files.

TensorFlow Guidelines.

  • TensorFlow code should follow the TensorFlow Style Guide.

  • TensorFlow code used with TFF should support both "graph mode" and "eager mode" execution. Good eager-mode design principles should be followed, including:

    • Avoid saving references to tensors where the value may change.
    • All TensorFlow functions should work correctly when annotated with tf.function. Such functions should only return multiple outputs (e.g., as a tuple) if it always makes sense to compute all of these values at the same time. The exception is Variable creation, which should always happen outside of @tf.function decorated functions.
    • Collections should not be used, unless it is unavoidable to support TF 1.0.
    • State such as tf.Variables should be tracked (only) by keeping a reference to the Python Variable object.
    • Use program-order-semantics in tf.functions rather than explicit control dependencies when possible. If line of code A should execute before line B, then the lines should occur in that order.
    • Don't write TF code which can only be correctly called once.

  • dict vs OrderedDict: Prefer OrderedDict. The names of tf.Variables may depend on the order in which they are created, due to name uniquification. Since dicts have arbitrary iteration order, this non-determinism can lead to Checkpoint-incompatible graphs. Furthermore, TFF type signatures constructed from unordered dictionaries may also mismatch as their entries are permuted.