Skip to content

Latest commit

 

History

History
88 lines (64 loc) · 3.71 KB

CONTRIBUTING.md

File metadata and controls

88 lines (64 loc) · 3.71 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.

Code Style, Guidelines, and Best Practices

General Guidelines

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

  • Python code must support Python2 and Python3 usage.

  • Include a license at the top of new files.

  • Generally, function names should be verbs, e.g. to_var_dict rather than var_dict.

TensorFlow-specific 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.

TFF-Learning-specific Guidelines

  • While not a requirement, in our examples we use the conventions that metrics and counters associated with a tff.learning.Model are named using lower_with_under style, as with Python identifiers.