Update docs on contributing and create initial maintainers doc.

PiperOrigin-RevId: 328425526

Author: alanchiao

CONTRIBUTING.md

@@ -21,9 +21,6 @@ again.
 
 ## TensorFlow Model Optimization Specific
 
-### Style
-Please refer to [TensorFlow's style guide](https://www.tensorflow.org/community/contribute/code_style). Don't forget to run pylint.
-
 ### Contributing Whole Techniques
 
 See these [guidelines](CONTRIBUTING_TECHNIQUE.md).
@@ -47,9 +44,17 @@ are good for new contributors.
 These guidelines seek to prioritize efforts that would benefit the community the most.
 Feedback is welcome.
 
+### Style and Practices
+* Please refer to [TensorFlow's style guide](https://www.tensorflow.org/community/contribute/code_style). Don't forget to run pylint.
+
+Unless agreed upon with the project maintainer in the issue or PR, the following are necessary to
+merge a PR.
+* Unit tests for behavioral changes. Keep in mind that unit tests that take a long time to run also make it harder to contribute.
+* New features and major bug fixes, when ready to share with users, should come with a modification to the [release notes for the next release](RELEASE.md).
+* Documentation changes for https://www.tensorflow.org/model_optimization, possibly making a note that something will only be available in the next release after X.Y.Z.
+* Cleanup of commit history by [squashing noisy commit messages](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History).
 
-New features and bug fixes for documented features should come with a
-modification to the [release notes](RELEASE.md).
+It is okay to not include all of the above in the initial PR, especially if early feedback is desired first.
 
 ## Code reviews
 

MAINTAINING.md

@@ -0,0 +1,37 @@
+This document is for maintainers.
+
+It is a work in progress and suggestions are welcome.
+
+# Triaging
+A issue or PR should only be assigned to someone if they would be actively working on
+it or would be working on it shortly. This avoids the scenario when we think
+everything is being addressed when that is not the case, particularly when people are
+busy, which may cause issues to invisibly languish.
+
+The [maintainer for a particular
+technique](https://github.com/tensorflow/model-optimization#maintainers) is
+responsible for that technique.
+
+Github PRs
+- The maintainers should watch out for PRs, filtered by the corresponding
+  technique label. For example, the label for quantization-aware training is
+  [here](https://github.com/tensorflow/model-optimization/pulls?q=is%3Apr+is%3Aopen+label%3Atechnique%3Aqat+).
+  This labeling is automated
+  [here](https://github.com/tensorflow/model-optimization/blob/master/.github/workflows/labeler.yml).
+
+Github Issues
+- The maintainers should skim through issues and attach the appropriate technique label. This has not been automated yet.
+- Use other labels as needed, according to [CONTRIBUTING.md](https://github.com/tensorflow/model-optimization/blob/master/CONTRIBUTING.md).
+
+# Code Reviews
+Ensure that contributions adhere to the guidelines suggested in
+[CONTRIBUTING.md](https://github.com/tensorflow/model-optimization/blob/master/CONTRIBUTING.md).
+Comments that are frequently made in PRs should be added there.
+
+If there are public API changes, please attach the ["api-review"
+label](https://github.com/tensorflow/model-optimization/pulls?q=is%3Apr+is%3Aopen+label%3Aapi-review)
+for a closer look from the TFMOT team.
+
+Once you think a PR is ready to merge, apply the ["ready to pull"
+label](https://github.com/tensorflow/model-optimization/pulls?q=is%3Apr+is%3Aopen+label%3A%22ready+to+pull%22)
+and someone will merge it.