docs: Add contributing documentation (#35)

* docs: Add contributing documentation

Signed-off-by: Darren Murray <[email protected]>

* docs: Address code review comments

Signed-off-by: Darren Murray <[email protected]>

* docs: Fix typo

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,28 @@
+---
+name: Bug report
+about: Create a report to help us improve
+title: 'bug:'
+labels: bug
+---
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**Steps to reproduce**
+
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.
+
+**Screenshots**
+If applicable, add screenshots to help explain your problem.
+
+**Please complete the following information):**
+ - Terraform Version: [e.g. v1.0.0 ]
+ - Module Version [e.g. v0.15.0] 
+
+Run `terraform version` to find your Terraform version.
+You can find the module version by running `terraform providers` or in your terraform configuration. If developing locally you can check the `VERSION` file in the project root directory.
+
+**Additional context**
+Add any other context about the problem here.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,20 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+title: 'feat: '
+labels: 'feat'
+---
+
+# Feature Request
+
+**Describe the Feature Request**
+A clear and concise description of what the feature request is. Please include if your feature request is related to a problem
+
+**Is your feature request related to a problem? Please describe**
+Problems related that made you consider this feature request
+
+**Describe Preferred Solution**
+A clear and concise description of what you want to happen and alternatives
+
+**Additional Context**
+List any other information that is relevant to your issue. Stack traces, related issues, suggestions on how to add, use case, Stack Overflow links, forum links, screenshots, OS if applicable, etc.

.github/pull-request-template.md

@@ -0,0 +1,13 @@
+---
+name: Pull request template
+about: 'type(scope): Subject of the pull request '
+---
+
+***Issue***: Include link to the Jira/Github Issue
+
+***Description:***
+Provide a detailed description of the changes made by this pull request.
+
+***Additional Info:***
+Include any other relevant information such as how to use the new fuctionality, screenshots, etc.
+

CONTRIBUTING.md

@@ -0,0 +1,40 @@
+# Contributing to the Lacework Terraform Modules
+
+### Table Of Contents
+
+* [Before getting started?](#before-getting-started)
+
+* [How to Contribute?](#how-can-i-contribute)
+    * [Reporting Bugs](#reporting-bugs)
+    * [Feature Requests](#feature-requests)
+    * [Pull Requests](#creating-a-pull-request)
+
+* [Developer Guidelines](/DEVELOPER_GUIDELINES.md)
+
+
+## Before getting started
+
+Read the [README.md](README.md) and
+ Hashicorps [best practices and syntax guidelines](https://www.terraform.io/docs/configuration/index.html)
+
+## Reporting Bugs
+
+Ensure the issue you are raising has not already been created under [issues](https://github.com/lacework/terraform-azure-activity-log/issues).
+If no current issue addresses the problem, open a new [issue](https://github.com/lacework/terraform-azure-activity-log/issues/new).
+Include as much relevant information as possible. See the [bug template](https://github.com/lacework/terraform-azure-activity-log/blob/main/.github/ISSUE_TEMPLATE/bug_report.md) for help on creating a new issue.
+
+## Feature Requests
+
+If you wish to submit a request to add new functionality or an improvement to a terraform module then use the the [feature request](https://github.com/lacework/terraform-azure-activity-log/blob/main/.github/ISSUE_TEMPLATE/feature_request.md) template to 
+open a new [issue](https://github.com/lacework/terraform-azure-activity-log/issues/new)
+
+## Creating a Pull Request
+
+If you have made a change or added new functionality, you can submit a pull request. The project maintainers will aim to review in a 2 week timeframe. When submitting a pull request please read the [developer guidelines](/DEVELOPER_GUIDELINES.md)
+
+The examples folder contains Terraform code that run as part of the CI pipeline. A new pull request will trigger this test run to ensure no breaking changes are added. We recommended sanity checking your own Terraform changes before submitting the change for review.
+
+
+Thanks,
+
+Project Maintainers

DEVELOPER_GUIDELINES.md

@@ -0,0 +1,162 @@
+## Terraform Modules Developer Guidelines
+
+### Installation
+It is recommended to use tfenv or tfswitch. This makes managing and switching between Terraform versions quick and easy.
+
+***TFenv***
+
+```brew install tfenv```
+To get up and running with TFenv refer to the Usage section of the README
+
+***TFSwitch***
+
+```brew install warrensbox/tap/tfswitch```
+To get up and running with TFSwitch refer to the documentation
+
+***Indentation***
+
+Use two spaces, no tabs.
+
+```hcl
+resource "aws_instance" "example" {
+  ami = "abc123"
+
+  network_interface {
+    # ...
+  }
+}
+```
+
+***Comments***
+
+Our best practice is to add a comment for every resource declared. This comment should explain what the resource is doing and how it interconnects with other resources. Hashicorp recommends using # for single-line comments.
+
+Here is an example of a resource with its comment:
+
+```hcl
+# Create the Lacework application within Azure Active Directory to grant
+# access to Azure Storage, Azure Key Vault, AAD Graph API, and Microsoft Graph
+resource "azuread_application" "default" {
+  ...
+}
+```
+
+
+***Input Variables***
+
+Always document user-facing variables, even if your variable names are self-descriptive like api_key or account, they could be easily misinterpreted. Always add a description field with a brief explanation.
+
+A couple of examples:
+
+
+```hcl
+variable "account" {
+  type        = string
+  description = "Lacework account subdomain of URL (i.e. <ACCOUNT>.lacework.net)"
+}
+```
+
+```hcl
+variable "api_key" {
+  type        = string
+  description = "A Lacework API access key"
+}
+```
+Additionally, any required variables like api keys, or required tagging should not have default values, and should require the user to input those either manually each run, or optimally using a terraform.tfvars file
+
+***Recommended Project File Organization***
+
+A few best practices for organizing Terraform projects: 
+
+* `main.tf` - Store the main structure of your terraform code in this file
+* `variables.tf` - All variables for your project
+* `output.tf` - All outputs in this file
+* `tfvars.example` - An example terraform.tfvars file for easy cp for users (note: *.tfvars are typically 
+ignored by .gitignore
+* `.gitignore` - Critical to ensure that any sensitive information used in tfvars are not checked in to git
+
+
+***Version Support / Documentation***
+
+Hashicorp release frequent patch and minor updates as needed, as well as new major releases of Terraform each year. Although Hashicorp provide solid documentation on how to upgrade between major releases of Terraform, Lacework must contend with the fact that Lacework customers do not all upgrade in a timely manor. For this reason Tech Alliances Team must continue to update documentation with supported versions of Terraform, as well as update CI pipelines to test changes across each supported version. 
+
+***Standard Versioning for Code Snippets***
+All customer facing code snippets should adhere to the standard of using pessimistic version constraint to minor releases. 
+
+```hcl
+module "aws_config" {
+  source  = "lacework/config/aws"
+  version = "~> 0.1"
+}
+```
+```hcl
+module "aws_cloudtrail" {
+  source  = "lacework/cloudtrail/aws"
+  version = "~> 0.1"
+
+  bucket_force_destroy  = true
+  use_existing_iam_role = true
+  iam_role_name         = module.aws_config.iam_role_name
+  iam_role_arn          = module.aws_config.iam_role_arn
+  iam_role_external_id  = module.aws_config.external_id
+}
+```
+
+The example above will work for version 0.1.9 as well as 0.4.0, but will not pull in any major releases such as 1.0.0.
+
+For more information visit [Semantic Versioning 2.0.0](https://semver.org/) 
+
+## Commit message standard
+
+The format is:
+
+```
+type(scope): subject
+BODY
+FOOTER
+```
+Each commit message consists of a header, body, and footer. The header is mandatory, the scope is optional, the type and subject are mandatory.
+When writing a commit message try and limit each line of the commit to a max of 100 hundred characters, so it can be read easily.
+
+### Type
+
+| Type | Description |
+| ----- | ----------- |
+| feat: | A new feature you're adding |
+| fix: |A bug fix|
+| style: | Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) |
+| refactor: | A code change that neither fixes a bug nor adds a feature |
+| test: | Everything related to testing |
+| docs: | Everything related to documentation |
+| chore: | Regular code maintenance |
+| build: | Changes that affect the build |
+| ci: | Changes to our CI configuration files and scripts |
+| perf: | A code change that improves performance |
+| metric: | A change that provides better insights about the adoption of features and code statistics |
+
+### Scope
+The optional scope refers to the section that this commit belongs to, for example, changing a specific component or service, a directive, pipes, etc. 
+Think about it as an indicator that will let the developers know at first glance what section of your code you are changing.
+
+A few good examples are:
+
+feat(client):
+docs(cli):
+chore(tests):
+ci(directive):
+
+### Subject
+The subject should contain a short description of the change, and written in present-tense, for example, use “add” and not “added”,  or “change” and not “changed”. 
+I like to fill this sentence below to understand what should I put as my description of my change:
+
+If applied, this commit will ________________________________________.
+
+### Body
+The body should contain a longer description of the change, try not to repeat the subject and keep it in the present tense as above. 
+Put as much context as you think it is needed, don’t be shy and explain your thought process, limitations, ideas for new features or fixes, etc.
+
+### Footer
+The footer is used to reference issues, pull requests or breaking changes, for example, “Fixes ticket #123”.
+
+## Signing commits
+Signed commits are required for any contribution to this project. Please see Github's documentation on configuring signed commits, [tell git about your signing key](https://docs.github.com/en/github/authenticating-to-github/managing-commit-signature-verification/telling-git-about-your-signing-key) and [signing commits](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits)

GNUmakefile

@@ -1,7 +1,17 @@
+.PHONY: help
+help:
+	@echo "-------------------------------------------------------------------"
+	@echo "Lacework terraform-azure-activity-log Makefile helper:"
+	@echo ""
+	@grep -Fh "##" $(MAKEFILE_LIST) | grep -v grep | sed -e 's/\\$$//' | sed -E 's/^([^:]*):.*##(.*)/ \1 -\2/'
+	@echo "-------------------------------------------------------------------"
+
 default: ci
 
-ci:
+.PHONY: ci
+ci: ## *CI ONLY* Runs tests on CI pipeline
 	scripts/ci_tests.sh
 
-release: ci
+.PHONY: release
+release: ci ## *CI ONLY* Prepares a release of the Terraform module
 	scripts/release.sh prepare