[APT-1691] Add Contributing and Forking sections

_docs-sources/guides/stay-up-to-date/cis/cis-1.3.0/deployment-walkthrough/step-1-update-references-to-the-gruntwork-infrastructure-as-code-library.md

@@ -18,7 +18,7 @@ To update to the CIS AWS Foundations Benchmark v1.3.0, you need to update your r
 Infrastructure as Code Library to use compatible versions. We (Gruntwork) have reviewed and updated all the library modules for compatibility with the new version of the Benchmark. As a customer, you need to update to
 the proper versions of the Gruntwork library to pick up the fixes/changes made to be compatible. Refer to
 [the
-"Updating to new versions" section of "Stay Up to Date"](/docs/guides/stay-up-to-date/versioning#updating-to-new-versions) for instructions on how to update the
+"Updating to new versions" section of "Stay Up to Date"](/docs/guides/working-with-code/versioning#updating-to-new-versions) for instructions on how to update the
 versions in your code.
 
 For the vast majority of the repos, the only change that will be necessary is a version number bump, but several repos
@@ -30,7 +30,7 @@ version.**
 
 Gruntwork follows
 [semantic
-versioning](/docs/guides/stay-up-to-date/versioning#semantic-versioning). For any pre-1.0 modules, this means that version updates to the minor version are considered backward
+versioning](/docs/guides/working-with-code/versioning#semantic-versioning). For any pre-1.0 modules, this means that version updates to the minor version are considered backward
 incompatible releases for any version updates before the 1.0.0 release. Make sure to read the release notes for the
 relevant modules any time you are updating minor versions! Note that you will want to read the release notes for each
 minor version that is updated (e.g., if you are going from v0.5.x to v0.9.x, you will want to read the notes for v0.6.0,

_docs-sources/guides/stay-up-to-date/cis/cis-1.4.0/deployment-walkthrough/step-1-update-references-to-the-gruntwork-infrastructure-as-code-library.md

@@ -7,12 +7,12 @@ sidebar_label: Update references to the Gruntwork Infrastructure as Code Library
 To update to the CIS AWS Foundations Benchmark v1.4.0, you need to update your references to the Gruntwork
 Infrastructure as Code Library to use compatible versions. We (Gruntwork) have reviewed and updated all the library
 modules for compatibility with the new version of the benchmark. As a customer, you need to update to
-the proper versions of the Gruntwork library to pick up the fixes/changes made to be compatible. Refer to our ["Updating to new versions"](/docs/guides/stay-up-to-date/versioning#updating-to-new-versions) guide for instructions on how to update the
+the proper versions of the Gruntwork library to pick up the fixes/changes made to be compatible. Refer to our ["Updating to new versions"](/docs/guides/working-with-code/versioning#updating-to-new-versions) guide for instructions on how to update the
 versions in your code.
 
 Gruntwork follows
 [semantic
-versioning](/docs/guides/stay-up-to-date/versioning#semantic-versioning). For any pre-1.0 modules, this means that version updates to the minor version are considered backward
+versioning](/docs/guides/working-with-code/versioning#semantic-versioning). For any pre-1.0 modules, this means that version updates to the minor version are considered backward
 incompatible releases for any version updates before the 1.0.0 release. Make sure to read the release notes for the
 relevant modules any time you are updating minor versions! Note that you will want to read the release notes for each
 minor version that is updated (e.g., if you are going from v0.5.x to v0.9.x, you will want to read the notes for v0.6.0,

_docs-sources/guides/stay-up-to-date/terraform/how-to-update-to-aws-provider-v3/deployment-walkthrough.md

@@ -8,7 +8,7 @@ library to test and update the code to be compatible with AWS provider version 3
 the proper versions of the Gruntwork library to pick up the fixes/changes that were made to be compatible. Be sure to
 read the release notes to know what changes need to be made to update to that version.
 
-Refer to our ["Updating to new versions"](/docs/guides/stay-up-to-date/versioning#updating-to-new-versions) guide
+Refer to our ["Updating to new versions"](/docs/guides/working-with-code/versioning#updating-to-new-versions) guide
 for instructions on how to update the versions in your code.
 
 The following table provides a summary of all the relevant Gruntwork AWS modules and the respective versions that are
@@ -17,7 +17,7 @@ compatible with AWS provider version 3.
 :::caution
 
 Gruntwork follows [semantic
-versioning](/docs/guides/stay-up-to-date/versioning#semantic-versioning).
+versioning](/docs/guides/working-with-code/versioning#semantic-versioning).
 For any pre-1.0 modules, this means that version updates to the minor version
 are considered backwards incompatible releases for any version updates prior to
 1.0.0 release. Make sure to read the release notes for the relevant modules any

_docs-sources/guides/stay-up-to-date/terraform/terraform-1.x/deployment-walkthrough/step-2-update-references-to-the-gruntwork-infrastructure-as-code-library.md

@@ -10,7 +10,7 @@ version. We (Gruntwork) have gone through all our modules in the library to test
 and update the code to be compatible with Terraform 1.x. As a customer, you need
 to update to the proper versions of the Gruntwork library to pick up the
 fixes/changes that we made to be compatible. Refer to [the "Updating to new versions" section of
-"Stay Up to Date"](/docs/guides/stay-up-to-date/versioning#updating-to-new-versions#updating)
+"Stay Up to Date"](/docs/guides/working-with-code/versioning#updating-to-new-versions#updating)
 for instructions on how to update the versions in your code.
 
 For the vast majority of the repos, the only change that will be necessary is a
@@ -22,7 +22,7 @@ changes need to be made to update to the new version.**
 :::caution
 
 Gruntwork follows [semantic
-versioning](/docs/guides/stay-up-to-date/versioning#semantic-versioning).
+versioning](/docs/guides/working-with-code/versioning#semantic-versioning).
 For any pre-1.0 modules, this means that version updates to the minor version
 are considered backwards incompatible releases for any version updates prior to
 1.0.0 release. Make sure to read the release notes for the relevant modules any

_docs-sources/guides/stay-up-to-date/terraform/terraform-13/deployment-walkthrough/step-3-update-references-to-the-gruntwork-infrastructure-as-code-library.md

@@ -7,7 +7,7 @@ sidebar_label: Update Gruntwork IaC module references
 In order to take advantage of the Terraform 0.13, you need to update your references to the Gruntwork
 Infrastructure as Code Library to use a compatible version. We (Gruntwork) have gone through all our modules in the
 library to test and update the code to be compatible with Terraform 0.13. As a customer, you need to update to
-the proper versions of the Gruntwork library to pick up the fixes/changes that were made to be compatible. Refer to our ["Updating to new versions"](/docs/guides/stay-up-to-date/versioning#updating-to-new-versions) guide for instructions on how to update the
+the proper versions of the Gruntwork library to pick up the fixes/changes that were made to be compatible. Refer to our ["Updating to new versions"](/docs/guides/working-with-code/versioning#updating-to-new-versions) guide for instructions on how to update the
 versions in your code.
 
 For the vast majority of the repos, the only change that will be necessary is a version number bump, but several repos
@@ -19,7 +19,7 @@ user, pay special attention to the release notes!
 :::caution
 
 Gruntwork follows [semantic
-versioning](/docs/guides/stay-up-to-date/versioning#semantic-versioning).
+versioning](/docs/guides/working-with-code/versioning#semantic-versioning).
 For any pre-1.0 modules, this means that version updates to the minor version
 are considered backwards incompatible releases for any version updates prior to
 1.0.0 release. Make sure to read the release notes for the relevant modules any

_docs-sources/guides/stay-up-to-date/terraform/terraform-14/deployment-walkthrough/step-3-update-references-to-the-gruntwork-infrastructure-as-code-library.md

@@ -7,7 +7,7 @@ sidebar_label: Update Gruntwork IaC module references
 In order to take advantage of the Terraform 0.14, you need to update your references to the Gruntwork
 Infrastructure as Code Library to use a compatible version. We (Gruntwork) have gone through all our modules in the
 library to test and update the code to be compatible with Terraform 0.14. As a customer, you need to update to
-the proper versions of the Gruntwork library to pick up the fixes/changes that we made to be compatible. Refer to our ["Updating to new versions"](/docs/guides/stay-up-to-date/versioning#updating-to-new-versions) guide for instructions on how to update the
+the proper versions of the Gruntwork library to pick up the fixes/changes that we made to be compatible. Refer to our ["Updating to new versions"](/docs/guides/working-with-code/versioning#updating-to-new-versions) guide for instructions on how to update the
 versions in your code.
 
 For the vast majority of the repos, the only change that will be necessary is a version number bump, but several repos
@@ -18,7 +18,7 @@ version.**
 :::caution
 
 Gruntwork follows [semantic
-versioning](/docs/guides/stay-up-to-date/versioning#semantic-versioning).
+versioning](/docs/guides/working-with-code/versioning#semantic-versioning).
 For any pre-1.0 modules, this means that version updates to the minor version
 are considered backwards incompatible releases for any version updates prior to
 1.0.0 release. Make sure to read the release notes for the relevant modules any

_docs-sources/guides/stay-up-to-date/terraform/terraform-15/deployment-walkthrough/step-3-update-references-to-the-gruntwork-infrastructure-as-code-library.md

@@ -7,7 +7,7 @@ sidebar_label: Update Gruntwork IaC module references
 In order to take advantage of the Terraform 0.15, you need to update your references to the Gruntwork
 Infrastructure as Code Library to use a compatible version. We (Gruntwork) have gone through all our modules in the
 library to test and update the code to be compatible with Terraform 0.15. As a customer, you need to update to
-the proper versions of the Gruntwork library to pick up the fixes/changes that we made to be compatible. Refer to our ["Updating to new versions"](/docs/guides/stay-up-to-date/versioning#updating-to-new-versions) guide for instructions on how to update the
+the proper versions of the Gruntwork library to pick up the fixes/changes that we made to be compatible. Refer to our ["Updating to new versions"](/docs/guides/working-with-code/versioning#updating-to-new-versions) guide for instructions on how to update the
 versions in your code.
 
 For the vast majority of the repos, the only change that will be necessary is a version number bump, but several repos
@@ -18,7 +18,7 @@ version.**
 :::caution
 
 Gruntwork follows [semantic
-versioning](/docs/guides/stay-up-to-date/versioning#semantic-versioning).
+versioning](/docs/guides/working-with-code/versioning#semantic-versioning).
 For any pre-1.0 modules, this means that version updates to the minor version
 are considered backwards incompatible releases for any version updates prior to
 1.0.0 release. Make sure to read the release notes for the relevant modules any

_docs-sources/guides/working-with-code/contributing.md

@@ -0,0 +1,51 @@
+---
+sidebar_label: "Contributing code"
+---
+
+# Contributing to the Gruntwork Infrastructure as Code Library
+
+Contributions to the Gruntwork Infrastructure as Code Library are very welcome and appreciated! If you find a bug or want to add a new
+feature or even contribute an entirely new module, we are very happy to accept
+[pull requests](https://help.github.com/articles/about-pull-requests/), provide feedback, and run your changes through
+our automated test suite.
+
+This section outlines the process for contributing.
+
+## File a GitHub issue
+
+Before starting any work, we recommend filing a GitHub issue in the appropriate repo. This is your chance to ask
+questions and get feedback from the maintainers and the community before you sink a lot of time into writing (possibly
+the wrong) code. If there is anything you’re unsure about, just ask!
+
+## Update the documentation
+
+We recommend updating the documentation _before_ updating any code (see
+[Readme Driven Development](http://tom.preston-werner.com/2010/08/23/readme-driven-development.html)). This ensures the
+documentation stays up to date and allows you to think through the problem at a high level before you get lost in the
+weeds of coding.
+
+## Update the tests
+
+We also recommend updating the automated tests _before_ updating any code (see
+[Test Driven Development](https://en.wikipedia.org/wiki/Test-driven_development)). That means you add or update a test
+case, verify that it’s failing with a clear error message, and then make the code changes to get that test to pass.
+This ensures the tests stay up to date and verify all the functionality in the repo, including whatever new
+functionality you’re adding in your contribution. The `test` folder in every repo will have documentation on how to run
+the tests locally.
+
+## Update the code
+
+At this point, make your code changes and use your new test case to verify that everything is working.
+
+## Create a pull request
+
+[Create a pull request](https://help.github.com/articles/creating-a-pull-request/) with your changes. Please make sure
+to include the following:
+
+1.  A description of the change, including a link to your GitHub issue.
+2.  Any notes on backwards incompatibility.
+
+## Merge and release
+
+The maintainers for the repo will review your code and provide feedback. If everything looks good, they will merge the
+code and release a new version.

_docs-sources/guides/working-with-code/forking.md

@@ -0,0 +1,55 @@
+---
+sidebar_label: "Forking our code"
+---
+
+# Forking the Gruntwork Infrastructure as Code Library
+
+The [Gruntwork Terms of Service](https://gruntwork.io/terms/) give you permissions to fork the code from the Gruntwork
+Infrastructure as Code Library into your own repos. This is useful if your company does not allow external dependencies (e.g., you
+have a company policy that requires all source code to be pulled from an internal GitHub Enterprise or BitBucket
+server) or if you need to make modifications to the Infrastructure as Code Library that you do not wish to contribute back to
+Gruntwork. This section will walk you through what you need to do to fork the code.
+
+The definition of an _Authorized User_ from the Gruntwork Terms of Service does NOT change if you fork the
+code. That is, if you create internal forks and give 50 users access to those internal forks, then the Gruntwork
+License requires that you pay for 50 Authorized Users.
+
+## How to fork the code
+
+Here is how you fork the code in the Gruntwork Infrastructure as Code Library:
+
+1.  Copy each Gruntwork repo into your private repositories.
+2.  You’ll also want to copy all the versioned releases (see the `/releases` page for each repo).
+3.  For repos that contain pre-built binaries (such as `ssh-grunt` mentioned earlier), you’ll want to copy those binaries
+    as well.
+4.  Within each repo, search for any cross-references to other Gruntwork repos. Most of the repos are standalone, but
+    some of the Terraform and Go code is shared across repos (e.g., the `package-kafka` and `package-zookeeper` repos
+    use the `module-asg` repo under the hood to run an Auto Scaling Group). You’ll need to update Terraform source URLs
+    and Go import statements from `github.com/gruntwork-io` to your private Git repo URLs.
+
+You’ll want to automate the entire process above and run it on a regular schedule (e.g., daily). The Gruntwork
+Infrastructure as Code Library is updated continuously, both by the Gruntwork team and contributions from our community
+of customers (see the monthly [Gruntwork Newsletter](https://blog.gruntwork.io/tagged/gruntwork-newsletter) for details),
+so you’ll want to pull in these updates as quickly as you can.
+
+## How to use your forked code
+
+Once you’ve forked the code, using it in is very similar to what is outlined in [Using Terraform Modules](/docs/intro/first-deployment/using-terraform-modules), except for the following differences:
+
+1.  Point the `source` URLs of your Terraform modules to your own Git repos, rather than the `gruntwork-io` GitHub org.
+2.  Point the `--repo` parameter of `gruntwork-install` to your own Git repos, rather than the `gruntwork-io` GitHub org.
+
+## Drawbacks to forking
+
+While forking is allowed under the Gruntwork Terms of Services, it has some downsides:
+
+- You have to do a lot of work up-front to copy the repos, releases, and pre-compiled binaries and update internal
+  links.
+- You have to do more work to run this process on a regular basis and deal with merge conflicts.
+- If your team isn’t directly using the Gruntwork GitHub repos on a regular basis, then you’re less likely to
+  participate in issues and pull requests, and you won’t be benefiting as much from the Gruntwork community.
+
+So, whenever possible, use the code directly from the `gruntwork-io` GitHub org, as documented in
+[Using Terraform Modules](/docs/intro/first-deployment/using-terraform-modules). If your team relies on NPM, Docker Hub, Maven Central,
+GitHub, or the Terraform Registry, using Gruntwork repos directly is no different. However, if your company completely
+bans all outside sources, then follow the instructions above to fork the code, and good luck!

docs/guides/stay-up-to-date/cis/cis-1.3.0/deployment-walkthrough/step-1-update-references-to-the-gruntwork-infrastructure-as-code-library.md

@@ -18,7 +18,7 @@ To update to the CIS AWS Foundations Benchmark v1.3.0, you need to update your r
 Infrastructure as Code Library to use compatible versions. We (Gruntwork) have reviewed and updated all the library modules for compatibility with the new version of the Benchmark. As a customer, you need to update to
 the proper versions of the Gruntwork library to pick up the fixes/changes made to be compatible. Refer to
 [the
-"Updating to new versions" section of "Stay Up to Date"](/docs/guides/stay-up-to-date/versioning#updating-to-new-versions) for instructions on how to update the
+"Updating to new versions" section of "Stay Up to Date"](/docs/guides/working-with-code/versioning#updating-to-new-versions) for instructions on how to update the
 versions in your code.
 
 For the vast majority of the repos, the only change that will be necessary is a version number bump, but several repos
@@ -30,7 +30,7 @@ version.**
 
 Gruntwork follows
 [semantic
-versioning](/docs/guides/stay-up-to-date/versioning#semantic-versioning). For any pre-1.0 modules, this means that version updates to the minor version are considered backward
+versioning](/docs/guides/working-with-code/versioning#semantic-versioning). For any pre-1.0 modules, this means that version updates to the minor version are considered backward
 incompatible releases for any version updates before the 1.0.0 release. Make sure to read the release notes for the
 relevant modules any time you are updating minor versions! Note that you will want to read the release notes for each
 minor version that is updated (e.g., if you are going from v0.5.x to v0.9.x, you will want to read the notes for v0.6.0,
@@ -187,5 +187,5 @@ compatible with CIS AWS v1.3.0:
 
 
 <!-- ##DOCS-SOURCER-START
-{"sourcePlugin":"Local File Copier","hash":"aa5571aa2e4120b6908dfd44eb066d12"}
+{"sourcePlugin":"Local File Copier","hash":"eb861e0394f4d2313c7442d627edc531"}
 ##DOCS-SOURCER-END -->