Update guideline ordering and align with public modules

Reordering is mostly based on having all repo-level guidelines together and then dive into the actual content/resources.

This includes addition of repo naming guidelines, more clarification around the expected files, and an update to the sample readme to add type, default, and required values for inputs. Most suggestions reflect what HashiCorp recommends/requires when using public registries. One of the big advantages with consistent naming is easier discoverability, but maybe open the door for us to scan the repos and build our own registry-like site for others to scan (rather than going to GitLab directly).

Reference documents:

• https://www.terraform.io/docs/registry/modules/publish.html#requirements
• https://www.terraform.io/docs/modules/index.html#standard-module-structure

README.md

@@ -2,6 +2,14 @@ In order to provide consistency of quality and minimize disruption to projects
 making use of these modules, developers are asked to adhere to the following 
 guidelines and standards for Terraform modules.
 
+
+# Repo Naming Guidelines
+
+All repos must use the naming pattern of **`<PROVIDER>-<NAME>`**, where `<PROVIDER>` reflects 
+the main provider for the infrastructure and `<NAME>` names the module (with additional 
+hyphens). Examples include `aws-ssh-bastion` or `aws-gitlab-runner`.
+
+
 # Documentation
 
 Every module should be well documented. Each module should include, at a 
@@ -9,23 +17,45 @@ minimum, documentation that describes:
 
 * Purpose & Description - include an architectural diagram, preferably using official [AWS architecture icons](https://aws.amazon.com/architecture/icons/).
 * Any preconditions or assumptions
-* Inputs for the module and their default values
+* Inputs for the module. Each input should include a description, type, default value (if applicable), and required flag (as yes/no)
 * Outputs provided by the module
 * Module versions (see below) and major changes included in those versions
 
-
 [sample-readme.md](sample-readme.md) provides a starter README.md file.
 
-# Tagging
+
+# Code Organization
+
+Every module should contain the following:
+
+- **`versions.tf`** - declaration of minimum Terraform and provider versions for the module
+- **`main.tf`** - the main resource file. Any submodules used should be declared here. If many resources are being managed, this file may be split into smaller resource-type-based files (`dns.tf`, `lb.tf`, `networking.tf`, etc.)
+- **`variables.tf`** - declaration of all variables (inputs), both required and non-required
+- **`outputs.tf`** - the outputs for the module
+- **`.gitignore`** - files to ignore. See [gitignore](gitignore) for a good starting point
+
+
+
+# Versioning
+
+Every major change should result in a new version number. _Breaking changes are always major changes._ To create a new version number, do the following:
+
+* Update your README.md to document the new version number and indicate what changed
+* After your change has been merged to master, tag it with the version number.
+
+Do **not** reuse version numbers.
+
+
+# Tagging of Resources
 
 Proper tagging of cloud resources helps to reduce maintenance efforts as well 
 as providing enhanced reporting capabilities from our AWS provider, DLT. 
 
 This [AWS Tagging Strategis document](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/) is also helpful.
 
-Note that in order to use cost allocation with DLT, some of the tag names are dictated to us [here](https://opscenter.dlt.com/hc/en-us/articles/235230267-How-To-Tag-Resources-for-Cost-Allocation-with-a-DLT-AWS-Account)
+Note that in order to use cost allocation with DLT, some of the tag names are dictated to us [here](https://opscenter.dlt.com/hc/en-us/articles/235230267-How-To-Tag-Resources-for-Cost-Allocation-with-a-DLT-AWS-Account).
 
-## Guidelines:
+## Guidelines
 * Tag names 
 	* should normally be CamelCase
 	* should consist of characters a-z, 0-9 and ‘-’ (dash)
@@ -33,7 +63,7 @@ Note that in order to use cost allocation with DLT, some of the tag names are di
 * Where a required tag doesn’t have a value or doesn’t apply, use the value ‘none’
 * As much as possible all tags should be automatically populated by whatever provisioning mechanism is being used.
 
-## Tags:
+## Expected Tags
 Every resource created by your modules should be tagged with the following:
 
 | Tag | Description | Default |
@@ -52,16 +82,6 @@ Every resource created by your modules should be tagged with the following:
 
 * Additional required tags may be added as business requirements arise, but aren't generally necessary in modules.
 
-# Code organization
-Every module should have at a minimum a `main.tf`, `variables.tf` and `.gitignore` at the root of the repository. Additional directories and files may be added according to the needs of the module. See [gitignore](gitignore) for a good starting point for that file.
-
-# Versioning
-Every major change should result in a new version number. _Breaking changes are always major changes._ To create a new version number, do the following:
-
-* Update your README.md to document the new version number and indicate what changed
-* After your change has been merged to master, tag it with the version number.
-
-Do **not** reuse version numbers.
 
 # Submitting merge requests