Home | History | Annotate | Download | only in tensorflow
      1 # Contributing guidelines
      2 
      3 ## How to become a contributor and submit your own code
      4 
      5 ### Contributor License Agreements
      6 
      7 We'd love to accept your patches! Before we can take them, we have to jump a couple of legal hurdles.
      8 
      9 Please fill out either the individual or corporate Contributor License Agreement (CLA).
     10 
     11   * 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](https://code.google.com/legal/individual-cla-v1.0.html).
     12   * If you work for a company that wants to allow you to contribute your work, then you'll need to sign a [corporate CLA](https://code.google.com/legal/corporate-cla-v1.0.html).
     13 
     14 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.
     15 
     16 ***NOTE***: Only original source code from you and other people that have signed the CLA can be accepted into the main repository.
     17 
     18 ### Contributing code
     19 
     20 If you have improvements to TensorFlow, send us your pull requests! For those
     21 just getting started, Github has a [howto](https://help.github.com/articles/using-pull-requests/).
     22 
     23 TensorFlow team members will be assigned to review your pull requests. Once the pull requests are approved and pass continuous integration checks, we will merge the pull requests.
     24 For some pull requests, we will apply the patch for each pull request to our internal version control system first, and export the change out as a new commit later, at which point the original pull request will be closed. The commits in the pull request will be squashed into a single commit with the pull request creator as the author. These pull requests will be labeled as pending merge internally.
     25 
     26 If you want to contribute but you're not sure where to start, take a look at the
     27 [issues with the "contributions welcome" label](https://github.com/tensorflow/tensorflow/labels/stat%3Acontributions%20welcome).
     28 These are issues that we believe are particularly well suited for outside
     29 contributions, often because we probably won't get to them right now. If you
     30 decide to start on an issue, leave a comment so that other people know that
     31 you're working on it. If you want to help out, but not alone, use the issue
     32 comment thread to coordinate.
     33 
     34 ### Contribution guidelines and standards
     35 
     36 Before sending your pull request for
     37 [review](https://github.com/tensorflow/tensorflow/pulls),
     38 make sure your changes are consistent with the guidelines and follow the
     39 TensorFlow coding style.
     40 
     41 #### General guidelines and philosophy for contribution
     42 
     43 * Include unit tests when you contribute new features, as they help to
     44   a) prove that your code works correctly, and b) guard against future breaking
     45   changes to lower the maintenance cost.
     46 * Bug fixes also generally require unit tests, because the presence of bugs
     47   usually indicates insufficient test coverage.
     48 * Keep API compatibility in mind when you change code in core TensorFlow,
     49   e.g., code in [tensorflow/core](https://github.com/tensorflow/tensorflow/tree/master/tensorflow/core) and  [tensorflow/python](https://github.com/tensorflow/tensorflow/tree/master/tensorflow/python).
     50   TensorFlow has reached version 1 and hence cannot make
     51   non-backward-compatible API changes without a major release. Reviewers of your
     52   pull request will comment on any API compatibility issues.
     53 * When you contribute a new feature to TensorFlow, the maintenance burden is (by
     54   default) transferred to the TensorFlow team. This means that benefit of the
     55   contribution must be compared against the cost of maintaining the feature.
     56 * Full new features (e.g., a new op implementing a cutting-edge algorithm)
     57   typically will live in
     58   [tensorflow/contrib](https://github.com/tensorflow/tensorflow/tree/master/tensorflow/contrib)
     59   to get some airtime before decision is made regarding whether they are to be
     60   migrated to the core.
     61 
     62 #### License
     63 
     64 Include a license at the top of new files.
     65 
     66 * [C/C++ license example](https://github.com/tensorflow/tensorflow/blob/master/tensorflow/core/framework/op.cc#L1)
     67 * [Python license example](https://github.com/tensorflow/tensorflow/blob/master/tensorflow/python/ops/nn.py#L1)
     68 * [Java license example](https://github.com/tensorflow/tensorflow/blob/master/tensorflow/java/src/main/java/org/tensorflow/Graph.java#L1)
     69 * [Go license example](https://github.com/tensorflow/tensorflow/blob/master/tensorflow/go/operation.go#L1)
     70 * [Bash license example](https://github.com/tensorflow/tensorflow/blob/master/tensorflow/tools/ci_build/ci_sanity.sh#L2)
     71 * [HTML license example](https://github.com/tensorflow/tensorboard/blob/master/tensorboard/components/tf_backend/tf-backend.html#L2)
     72 * [JavaScript/TypeScript license example](https://github.com/tensorflow/tensorboard/blob/master/tensorboard/components/tf_backend/backend.ts#L1)
     73 
     74 Bazel BUILD files also need to include a license section, e.g.,
     75 [BUILD example](https://github.com/tensorflow/tensorflow/blob/master/tensorflow/core/BUILD#L61).
     76 
     77 #### C++ coding style
     78 
     79 Changes to TensorFlow C++ code should conform to
     80 [Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html).
     81 
     82 Use `clang-tidy` to check your C/C++ changes. To install clang-tidy on ubuntu:16.04, do:
     83 
     84 ```bash
     85 apt-get install -y clang-tidy
     86 ```
     87 
     88 You can check a C/C++ file by doing:
     89 
     90 
     91 ```bash
     92 clang-format <my_cc_file> --style=google > /tmp/my_cc_file.cc
     93 diff <my_cc_file> /tmp/my_cc_file.cc
     94 ```
     95 
     96 #### Python coding style
     97 
     98 Changes to TensorFlow Python code should conform to
     99 [Google Python Style Guide](https://google.github.io/styleguide/pyguide.html)
    100 
    101 Use `pylint` to check your Python changes. To install `pylint` and
    102 retrieve TensorFlow's custom style definition:
    103 
    104 ```bash
    105 pip install pylint
    106 wget -O /tmp/pylintrc https://raw.githubusercontent.com/tensorflow/tensorflow/master/tensorflow/tools/ci_build/pylintrc
    107 ```
    108 
    109 To check a file with `pylint`:
    110 
    111 ```bash
    112 pylint --rcfile=/tmp/pylintrc myfile.py
    113 ```
    114 
    115 #### Coding style for other languages
    116 
    117 * [Google Java Style Guide](https://google.github.io/styleguide/javaguide.html)
    118 * [Google JavaScript Style Guide](https://google.github.io/styleguide/jsguide.html)
    119 * [Google Shell Style Guide](https://google.github.io/styleguide/shell.xml)
    120 * [Google Objective-C Style Guide](https://google.github.io/styleguide/objcguide.html)
    121 
    122 #### Running sanity check
    123 
    124 If you have Docker installed on your system, you can perform a sanity check on
    125 your changes by running the command:
    126 
    127 ```bash
    128 tensorflow/tools/ci_build/ci_build.sh CPU tensorflow/tools/ci_build/ci_sanity.sh
    129 ```
    130 
    131 This will catch most license, Python coding style and BUILD file issues that
    132 may exist in your changes.
    133 
    134 #### Running unit tests
    135 
    136 There are two ways to run TensorFlow unit tests.
    137 
    138 1. Using tools and libraries installed directly on your system.
    139 
    140    Refer to the
    141    [CPU-only developer Dockerfile](https://github.com/tensorflow/tensorflow/blob/master/tensorflow/tools/docker/Dockerfile.devel) and
    142    [GPU developer Dockerfile](https://github.com/tensorflow/tensorflow/blob/master/tensorflow/tools/docker/Dockerfile.devel-gpu)
    143    for the required packages. Alternatively, use the said
    144    [Docker images](https://hub.docker.com/r/tensorflow/tensorflow/tags/), e.g.,
    145    `tensorflow/tensorflow:nightly-devel` and `tensorflow/tensorflow:nightly-devel-gpu`
    146    for development to avoid installing the packages directly on your system.
    147 
    148    Once you have the packages installed, you can run a specific unit test in
    149    bazel by doing as follows:
    150 
    151    If the tests are to be run on GPU, add CUDA paths to LD_LIBRARY_PATH and add
    152    the `cuda` option flag
    153 
    154    ```bash
    155    export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/local/cuda/lib64:/usr/local/cuda/extras/CUPTI/lib64:$LD_LIBRARY_PATH"
    156 
    157    export flags="--config=opt --config=cuda -k"
    158    ```
    159 
    160    For example, to run all tests under tensorflow/python, do:
    161 
    162    ```bash
    163    bazel test ${flags} //tensorflow/python/...
    164    ```
    165 
    166 2. Using [Docker](https://www.docker.com) and TensorFlow's CI scripts.
    167 
    168    ```bash
    169    # Install Docker first, then this will build and run cpu tests
    170    tensorflow/tools/ci_build/ci_build.sh CPU bazel test //tensorflow/...
    171    ```
    172 
    173    See
    174    [TensorFlow Builds](https://github.com/tensorflow/tensorflow/tree/master/tensorflow/tools/ci_build) for details.
    175 
    176