Skip to content
This repository has been archived by the owner on Jul 1, 2023. It is now read-only.

Latest commit

 

History

History
93 lines (66 loc) · 3.8 KB

CONTRIBUTING.md

File metadata and controls

93 lines (66 loc) · 3.8 KB
Raw

Contributing guidelines

Welcome!

swift-apis is a carefully curated set of maintained APIs and functionality. We generally aim to incubate new features in the library ecosystem that builds on top of Swift for TensorFlow. Popular functionality, such as new layers or helpful abstractions, often graduate into swift-apis after maturing in other repositories first (e.g. swift-models), where the development team and the community can try them out in context and iterate quickly.

How to become a contributor and submit your own code

Contributor License Agreements

We'd love to accept your patches! Before we can take them, there are just a few small guidelines to follow.

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.

Contributing code

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.

Contribution guidelines and standards

Before sending your pull request for review, make sure your changes are consistent with the guidelines.

Testing

  • Include unit tests when you contribute new features, as they help to a) prove that your code works correctly, and b) guard against future breaking changes to lower the maintenance cost.
  • Bug fixes also generally require unit tests, because the presence of bugs usually indicates insufficient test coverage.

License

Include a license at the top of new files.

Swift coding style

Changes should conform to:

With the exception that 4-space indendation be used.

API documentation guidelines

API documentation should follow guidelines from the "Write a documentation comment" section of the Swift API Design Guidelines:

  • Use Swift’s dialect of Markdown.
  • Begin with a summary that describes the entity being declared. Often, an API can be completely understood from its declaration and its summary.
  • Optionally, continue with one or more paragraphs and bullet items. Paragraphs are separated by blank lines and use complete sentences.

For APIs ported from Python TensorFlow, use the API documentation from tensorflow.org/api_docs (e.g. function parameter descriptions) as a starting point.

Community

It's a good idea to discuss any non-trivial submissions with the project maintainers before submitting a pull request: please join the [email protected] mailing list to do this.