diff --git a/terraform-google-{{cookiecutter.module_name}}/CONTRIBUTING.md b/terraform-google-{{cookiecutter.module_name}}/CONTRIBUTING.md
index f321362..fc745e9 100644
--- a/terraform-google-{{cookiecutter.module_name}}/CONTRIBUTING.md
+++ b/terraform-google-{{cookiecutter.module_name}}/CONTRIBUTING.md
@@ -1,8 +1,29 @@
# Contributing
-This document provides guidelines for contributing to the module.
+We'd love to accept your patches and contributions to this project. There are
+just a few small guidelines you need to follow.
-## Dependencies
+## Contributor License Agreement
+
+Contributions to this project must be accompanied by a Contributor License
+Agreement (CLA). You (or your employer) retain the copyright to your
+contribution; this simply gives us permission to use and redistribute your
+contributions as part of the project. Head over to
+ to see your current agreements on file or
+to sign a new one.
+
+You generally only need to submit a CLA once, so if you've already submitted one
+(even if it was for a different project), you probably don't need to do it
+again.
+
+## Code Reviews
+
+All submissions, including submissions by project members, require review. We
+use GitHub pull requests for this purpose. Consult
+[GitHub Help](https://help.github.com/articles/about-pull-requests/) for more
+information on using pull requests.
+
+## Development
The following dependencies must be installed on the development system:
@@ -10,18 +31,18 @@ The following dependencies must be installed on the development system:
- [Google Cloud SDK][google-cloud-sdk]
- [make]
-## Generating Documentation for Inputs and Outputs
+### Generating Documentation for Inputs and Outputs
The Inputs and Outputs tables in the READMEs of the root module,
submodules, and example modules are automatically generated based on
the `variables` and `outputs` of the respective modules. These tables
must be refreshed if the module interfaces are changed.
-### Execution
+#### Execution
Run `make generate_docs` to generate new Inputs and Outputs tables.
-## Integration Testing
+### Integration Testing
Integration tests are used to verify the behaviour of the root module,
submodules, and example modules. Additions, changes, and fixes should
@@ -35,7 +56,7 @@ The general strategy for these tests is to verify the behaviour of the
[example modules](./examples/), thus ensuring that the root module,
submodules, and example modules are all functionally correct.
-### Test Environment
+#### Test Environment
The easiest way to test the module is in an isolated test project. The setup for such a project is defined in [test/setup](./test/setup/) directory.
To use this setup, you need a service account with these permissions (on a Folder or Organization):
@@ -67,12 +88,12 @@ With these settings in place, you can prepare a test project using Docker:
make docker_test_prepare
```
-### Noninteractive Execution
+#### Noninteractive Execution
Run `make docker_test_integration` to test all of the example modules
noninteractively, using the prepared test project.
-### Interactive Execution
+#### Interactive Execution
1. Run `make docker_run` to start the testing Docker container in
interactive mode.
@@ -87,12 +108,12 @@ noninteractively, using the prepared test project.
1. Run `kitchen_do destroy ` to destroy the example module
state.
-## Linting and Formatting
+### Linting and Formatting
Many of the files in the repository can be linted or formatted to
maintain a standard of quality.
-### Execution
+#### Execution
Run `make docker_test_lint`.