|
| 1 | +# Contributing guidelines |
| 2 | +```Last Updated: 2018年08月16日 by Javier Cañon``` |
| 3 | + |
| 4 | +## Pull Request Checklist |
| 5 | + |
| 6 | +Before sending your pull requests, make sure you followed this list. |
| 7 | + |
| 8 | +- Read [contributing guidelines](CONTRIBUTING.md). |
| 9 | +- Read [Code of Conduct](CODE_OF_CONDUCT.md). |
| 10 | +- Check if my changes are consistent with the guidelines. |
| 11 | +- Changes are consistent with the Coding Style. |
| 12 | +- Run Unit Tests. |
| 13 | + |
| 14 | +## How to become a contributor and submit your own code |
| 15 | + |
| 16 | +### Contributor License Agreements |
| 17 | + |
| 18 | +We'd love to accept your patches! Before we can take them, we have to jump a couple of legal hurdles. |
| 19 | +Please read the License Agreement. |
| 20 | +***NOTE***: Only original source code from you and other people can be accepted into the main repository. |
| 21 | + |
| 22 | +### Contributing code |
| 23 | + |
| 24 | +If you have improvements to TensorFlow, send us your pull requests! For those |
| 25 | +just getting started, Github has a [howto](https://help.github.com/articles/using-pull-requests/). |
| 26 | + |
| 27 | +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. |
| 28 | +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. |
| 29 | + |
| 30 | +If you want to contribute but you're not sure where to start, |
| 31 | +take a look at the issues section. |
| 32 | + |
| 33 | +These are issues that we believe are particularly well suited for outside |
| 34 | +contributions, often because we probably won't get to them right now. If you |
| 35 | +decide to start on an issue, leave a comment so that other people know that |
| 36 | +you're working on it. If you want to help out, but not alone, use the issue |
| 37 | +comment thread to coordinate. |
| 38 | + |
| 39 | +### Contribution guidelines and standards |
| 40 | + |
| 41 | +Before sending your pull request for review |
| 42 | +make sure your changes are consistent with the guidelines and follow the coding style. |
| 43 | + |
| 44 | +#### General guidelines and philosophy for contribution |
| 45 | + |
| 46 | +* Include unit tests when you contribute new features, as they help to |
| 47 | + a) prove that your code works correctly, and b) guard against future breaking |
| 48 | + changes to lower the maintenance cost. |
| 49 | +* Bug fixes also generally require unit tests, because the presence of bugs |
| 50 | + usually indicates insufficient test coverage. |
| 51 | +* Keep compatibility in mind when you change code in core; |
| 52 | + e.g., code has reached version 1 and hence cannot make |
| 53 | + non-backward-compatible changes without a major release. Reviewers of your |
| 54 | + pull request will comment on any compatibility issues. |
| 55 | +* When you contribute a new feature, the maintenance burden is (by |
| 56 | + default) transferred to the team. This means that benefit of the |
| 57 | + contribution must be compared against the cost of maintaining the feature. |
| 58 | +* Full new features (e.g., a new op implementing a cutting-edge algorithm) |
| 59 | + typically will live in a branch,to get some airtime before decision |
| 60 | + is made regarding whether they are to be migrated to the core. |
| 61 | + |
| 62 | +#### License |
| 63 | + |
| 64 | +Include a (the) license at the top of new files you can use a developer tool, |
| 65 | +e.g.: [License Header Manager](https://github.com/rubicon-oss/LicenseHeaderManager) |
| 66 | + |
| 67 | +#### Coding style languages |
| 68 | + |
| 69 | +* [Microsoft C# and .NET Style Guide](https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/) |
| 70 | +* [Google Java Style Guide](https://google.github.io/styleguide/javaguide.html) |
| 71 | +* [Google JavaScript Style Guide](https://google.github.io/styleguide/jsguide.html) |
| 72 | +* [Google Shell Style Guide](https://google.github.io/styleguide/shell.xml) |
| 73 | +* [Google Objective-C Style Guide](https://google.github.io/styleguide/objcguide.html) |
| 74 | +* [Google Python Style Guide](https://github.com/google/styleguide/blob/gh-pages/pyguide.md) |
| 75 | +* [Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html). |
| 76 | + |
| 77 | + |
| 78 | +#### Running unit tests |
| 79 | + |
| 80 | +There are many ways to run unit tests, like: |
| 81 | +1. Using tools and libraries installed directly on your system. |
| 82 | +2. Using [Docker](https://www.docker.com). [Microsoft Docker Help](https://docs.microsoft.com/en-us/dotnet/core/docker/). |
| 83 | +3. [Visual Studio Unit Testing](https://docs.microsoft.com/en-us/dotnet/core/testing/) |
| 84 | + |
| 85 | + |
0 commit comments