1<!--
2emi-automated TOC generation with instructions from
3https://github.com/ekalinin/github-markdown-toc#auto-insert-and-update-toc
4-->
5<!--ts-->
6   * [How to Contribute](#how-to-contribute)
7      * [Contributor License Agreement](#contributor-license-agreement)
8      * [Community Guidelines](#community-guidelines)
9   * [Code Contribution Guidelines](#code-contribution-guidelines)
10      * [General Pull Request Guidelines](#general-pull-request-guidelines)
11      * [Guidelines for Specific Contribution Categories](#guidelines-for-specific-contribution-categories)
12         * [Bug Fixes](#bug-fixes)
13         * [Reference Kernel Implementations](#reference-kernel-implementations)
14         * [Optimized Kernel Implementations](#optimized-kernel-implementations)
15         * [New Target / Platform / IDE / Examples](#new-target--platform--ide--examples)
16         * [New Features](#new-features)
17   * [Development Workflow Notes](#development-workflow-notes)
18      * [Initial Setup](#initial-setup)
19      * [Before submitting your PR](#before-submitting-your-pr)
20      * [During the PR review](#during-the-pr-review)
21      * [Reviewer notes](#reviewer-notes)
22      * [Python notes](#python-notes)
23   * [Continuous Integration System](#continuous-integration-system)
24
25<!-- Added by: advaitjain, at: Fri 09 Apr 2021 12:51:55 PM PDT -->
26
27<!--te-->
28
29# How to Contribute
30
31We'd love to accept your patches and contributions to this project. There are
32just a few small guidelines you need to follow.
33
34## Contributor License Agreement
35
36Contributions to this project must be accompanied by a Contributor License
37Agreement (CLA). You (or your employer) retain the copyright to your
38contribution; this simply gives us permission to use and redistribute your
39contributions as part of the project. Head over to
40<https://cla.developers.google.com/> to see your current agreements on file or
41to sign a new one.
42
43You generally only need to submit a CLA once, so if you've already submitted one
44(even if it was for a different project), you probably don't need to do it
45again.
46
47## Community Guidelines
48
49This project follows
50[Google's Open Source Community Guidelines](https://opensource.google/conduct/).
51
52# Code Contribution Guidelines
53
54We provide some general guidelines with the goal of enabling community
55contributions while still maintaining code health, maintainability, and
56consistency in style.
57
58Please note that while these guidelines may seem onerous to some developers,
59they are derived from Google's software engineering best practices.
60
61Before we describe project-specific guidelines, we recommend that external
62contributors read these tips from the Google Testing Blog:
63
64*   [Code Health: Providing Context with Commit Messages and Bug Reports](https://testing.googleblog.com/2017/09/code-health-providing-context-with.html)
65*   [Code Health: Understanding Code In Review](https://testing.googleblog.com/2018/05/code-health-understanding-code-in-review.html)
66*   [Code Health: Too Many Comments on Your Code Reviews?](https://testing.googleblog.com/2017/06/code-health-too-many-comments-on-your.html)
67*   [Code Health: To Comment or Not to Comment?](https://testing.googleblog.com/2017/07/code-health-to-comment-or-not-to-comment.html)
68
69We also recommend that contributors take a look at the
70[Tensorflow Contributing Guidelines](https://github.com/tensorflow/tensorflow/blob/master/CONTRIBUTING.md).
71
72## General Pull Request Guidelines
73
74We strongly recommend that contributors:
75
761.  Initiate a conversation with the TFLM team via a
77    [TF Lite Micro Github issue](https://github.com/tensorflow/tensorflow/issues/new?labels=comp%3Amicro&template=70-tflite-micro-issue.md)
78    as early as possible.
79
80    *   This enables us to give guidance on how to proceed, prevent duplicated
81        effort and also point to alternatives as well as context if we are not
82        able to accept a particular contribution at a given time.
83
84    *   Ideally, you should make an issue ***before*** starting to work on a
85        pull request and provide context on both what you want to contribute and
86        why.
87
881.  Once step 1. is complete and it is determined that a PR from an external
89    contributor is the way to go, please follow these guidelines from
90    [Google's Engineering Practices documentation](https://google.github.io/eng-practices/):
91
92    *   [Send Small Pull Requests](https://google.github.io/eng-practices/review/developer/small-cls.html)
93
94        *   If a pull request is doing more than one thing, the reviewer will
95            request that it be broken up into two or more PRs.
96
97    *   [Write Good Pull Request Descriptions](https://google.github.io/eng-practices/review/developer/cl-descriptions.html)
98
99        *   We require that all PR descriptions link to the github issue created
100            in step 1.
101
102        *   While github offers flexibility in linking
103            [commits and issues](https://github.blog/2011-04-09-issues-2-0-the-next-generation/#commits-issues),
104            we require that the PR description have a separate line with
105            `BUG=#nn`.
106
107        *   We will be adding internal checks that automate this requirement by
108            matching the PR description to the regexp: `(Fixes|Issue) #`
109
1101.  Unit tests are critical to a healthy codebase. PRs without tests should be
111    the exception rather than the norm. And contributions to improve, simplify,
112    or make the unit tests more exhaustive are welcome! Please refer to
113    [this guideline](https://google.github.io/eng-practices/review/developer/small-cls.html#test_code)
114    on how test code and writing small PRs should be reconciled.
115
116## Guidelines for Specific Contribution Categories
117
118We provide some additional guidelines for different categories of contributions.
119
120### Bug Fixes
121
122Pull requests that fix bugs are always welcome and often uncontroversial, unless
123there is a conflict between different requirements from the platform, or if
124fixing a bug needs a bigger architectural change.
125
1261.  Create a
127    [TF Lite Micro Github issue](https://github.com/tensorflow/tensorflow/issues/new?labels=comp%3Amicro&template=70-tflite-micro-issue.md)
128    to determine the scope of the bug fix.
1291.  Send a PR (if that is determined to be the best path forward).
1301.  Bugfix PRs should be accompanied by a test case that fails prior to the fix
131    and passes with the fix. This validates that the fix works as expected, and
132    helps prevent future regressions.
133
134### Reference Kernel Implementations
135
136Pull requests that port reference kernels from TF Lite Mobile to TF Lite Micro
137are welcome once we have enough context from the contributor on why the
138additional kernel is needed.
139
1401.  Please create a
141    [TF Lite Micro Github issue](https://github.com/tensorflow/tensorflow/issues/new?labels=comp%3Amicro&template=70-tflite-micro-issue.md)
142    before starting on any such PRs with as much context as possible, such as:
143
144    *   What is the model architecture?
145    *   What is the application that you are targetting?
146    *   What embedded target(s) are you planning to run on?
147    *   Motivate your use-case and the need for adding support for this
148        additional OP.
149
1501.  In the interest of having
151    [small pull requests](https://google.github.io/eng-practices/review/developer/small-cls.html),
152    limit each pull request to porting a single kernel (and the corresponding
153    test).
154
1551.  TODO(b/165627437): Create and link to a guide to porting reference ops.
156
157### Optimized Kernel Implementations
158
159In order to have the TFLM codebase be a central repository of optimized kernel
160implementations, we would like to make some improvements to the current
161infrastructure to enable adding and maintaining optimized kernel implementations
162in a scalable way.
163
164Until that work is complete, we are requesting a ***pause*** on contributions that
165add new optimized kernel implementations. We plan to make these improvements by
166October 2020 and will provide additional guidelines at that time.
167
168*   If you would like to have an exception to this pause, with the understanding
169    that your optimized kernels will break as we improve the underlying
170    framework, then please send an email to the [SIG Micro email
171    group](https://groups.google.com/a/tensorflow.org/g/micro) to figure out
172    a middle ground.
173
174*   Every optimized kernel directory must have a README.md with the github IDs
175    of the maintainers and any other relevant documentation. PRs that add
176    maintainers to the existing optimized kernels are always welcome.
177
178### New Target / Platform / IDE / Examples
179
180As discussed in the
181[SIG-micro Aug 12, 2020 meeting](http://doc/1YHq9rmhrOUdcZnrEnVCWvd87s2wQbq4z17HbeRl-DBc),
182we are currently ***pausing*** accepting pull requests that add new targets,
183platforms, IDE integration or examples while we revisit some of the
184infrastructure to enable us to make this process easier and more scalable.
185
186In the meantime, snapshotting and/or forking the tensorflow repo could be a
187viable way to prototype platform support.
188
189Having said that, we still invite
190[TF Lite Micro Github issues](https://github.com/tensorflow/tensorflow/issues/new?labels=comp%3Amicro&template=70-tflite-micro-issue.md)
191on this topic as we would like to enable such integration in the future.
192
193### New Features
194
195As discussed in the
196[SIG-micro Aug 12, 2020 meeting](http://doc/1YHq9rmhrOUdcZnrEnVCWvd87s2wQbq4z17HbeRl-DBc),
197we are currently ***pausing*** accepting pull requests that add new features while
198we revisit some of the infrastructure to enable us to make this process easier
199and more scalable.
200
201Having said that, we still invite feature requests via
202[TF Lite Micro Github issues](https://github.com/tensorflow/tensorflow/issues/new?labels=comp%3Amicro&template=70-tflite-micro-issue.md)
203to determine if the requested feature aligns with the TFLM roadmap.
204
205# Development Workflow Notes
206
207## Initial Setup
208
209Below are some tips that might be useful and improve the development experience.
210
211* Add the [Refined GitHub](https://github.com/sindresorhus/refined-github)
212  plugin to make the github experience even better.
213
214* Code search the [TfLite Micro codebase](https://sourcegraph.com/github.com/tensorflow/tflite-micro@main)
215  on Sourcegraph. And optionally install the [plugin that enables GitHub integration](https://docs.sourcegraph.com/integration/github#github-integration-with-sourcegraph).
216
217* Install [bazel](ci/install_bazel.sh) and [buildifier](ci/install_buildifier.sh).
218
219* Install the latest clang and clang-format. For example, [here](ci/Dockerfile.micro)
220  is the what we do for the TFLM continuous integration Docker container.
221
222* Get a copy of [cpplint](https://github.com/google/styleguide/tree/gh-pages/cpplint)
223
224* [yapf](https://github.com/google/yapf/) should be used for formatting Python
225  code. For example:
226
227  ```
228  pip3 install yapf
229  yapf log_parser.py -i --style='{based_on_style: pep8, indent_width: 2}'
230  ```
231
232* Add a git hook to check for code style etc. prior to creating a pull request:
233  ```
234  cp tensorflow/lite/micro/tools/dev_setup/pre-push.tflm .git/hooks/pre-push
235  ```
236
237## Before submitting your PR
238
2391.  Run in-place clang-format on all the files that are modified in your git
240    tree with
241
242    ```
243    clang-format -i -style=google `git ls-files -m | grep "\.cc"`
244    clang-format -i -style=google `git ls-files -m | grep "\.h"`
245    ```
246
2471.  Make sure your code is lint-free.
248
249    ```
250    cpplint.py `git ls-files -m`
251    ```
252
2531.  Run all the tests for x86, and any other platform that you are modifying.
254
255    ```
256    tensorflow/lite/micro/tools/ci_build/test_x86.sh
257    ```
258
259    Please check the READMEs in the optimized kernel directories for specific
260    instructions.
261
2621.  Sometimes, bugs are caught by the sanitizers that can go unnoticed
263    via the Makefile. To run a test with the different sanitizers, use the
264    following commands (replace `micro_interpreter_test` with the target that you
265    want to test:
266
267    ```
268    CC=clang bazel run --config=asan tensorflow/lite/micro:micro_interpreter_test
269    CC=clang bazel run --config=msan tensorflow/lite/micro:micro_interpreter_test
270    CC=clang bazel run --config=ubsan tensorflow/lite/micro:micro_interpreter_test
271    ```
272
273## During the PR review
274
2751.  Do not change the git version history.
276
277    *   Always merge upstream/main (***do not rebase***) and no force-pushes
278        please.
279
280    *   Having an extra merge commit it ok as the github review tool handles
281        that gracefully.
282
283    Assuming that you forked tensorflow and added a remote called upstream with:
284
285    ```
286    git remote add upstream https://github.com/tensorflow/tflite-micro.git
287    ```
288
289    Fetch the latest changes from upstream and merge into your local branch.
290
291    ```
292    git fetch upstream
293    git merge upstream/main
294    ```
295
296    In case of a merge conflict, resolve via:
297
298    ```
299    git mergetool
300
301    # Use your favorite diff tools (e.g. meld) to resolve the conflicts.
302
303    git add <files that were manually resolved>
304
305    git commit
306    ```
307
3081.  If a force push seems to be the only path forward, please stop and let your
309    PR reviewer know ***before*** force pushing. We will attempt to do the merge
310    for you. This will also help us better understand in what conditions a
311    force-push may be unavoidable.
312
313## Reviewer notes
314
315*   [GIthub CLI](https://cli.github.com) can be useful to quickly checkout a PR
316    to test locally.
317
318    `gh pr checkout <PR number>`
319
320*   Google engineers on the Tensorflow team will have the permissions to push
321    edits to most PRs. This can be useful to make some small fixes as a result
322    of errors due to internal checks that are not easily reproducible via
323    github.
324
325    One example of this is
326    [this comment](https://github.com/tensorflow/tensorflow/pull/38634#issuecomment-683190474).
327
328    And a sketch of the steps:
329
330    ```
331    git remote add <remote_name> git@github.com:<PR author>/tensorflow.git
332    git fetch <remote_name>
333
334    git checkout -b <local-branch-name> <remote_name>/<PR branch name>
335
336    # make changes and commit to local branch
337
338    # push changes to remove branch
339
340    git push <remote_name> <PR branch name>
341
342    # remove the temp remote to clean up your git environment.
343
344    git remote rm <remote_name>
345    ```
346
347## Python notes
348
349*   [TensorFlow guide](https://www.tensorflow.org/community/contribute/code_style#python_style)
350    for Python development
351
352# Continuous Integration System
353  * Some [additional documentation](docs/continuous_integration.md) on the TFLM CI.
354