github.com/tetrafolium/tflint@v0.8.0/tflint/test-fixtures/v0.11.0_module/.terraform/modules/abc3234899392665e7e4875ddfd1340d/hashicorp-terraform-aws-consul-ee980b4/CONTRIBUTING.md (about)

     1  # Contribution Guidelines
     2  
     3  Contributions to this Module are very welcome! We follow a fairly standard [pull request 
     4  process](https://help.github.com/articles/about-pull-requests/) for contributions, subject to the following guidelines:
     5   
     6  1. [File a GitHub issue](#file-a-github-issue)
     7  1. [Update the documentation](#update-the-documentation)
     8  1. [Update the tests](#update-the-tests)
     9  1. [Update the code](#update-the-code)
    10  1. [Create a pull request](#create-a-pull-request)
    11  1. [Merge and release](#merge-and-release)
    12  
    13  ## File a GitHub issue
    14  
    15  Before starting any work, we recommend filing a GitHub issue in this repo. This is your chance to ask questions and
    16  get feedback from the maintainers and the community before you sink a lot of time into writing (possibly the wrong) 
    17  code. If there is anything you're unsure about, just ask!
    18  
    19  ## Update the documentation
    20  
    21  We recommend updating the documentation *before* updating any code (see [Readme Driven 
    22  Development](http://tom.preston-werner.com/2010/08/23/readme-driven-development.html)). This ensures the documentation 
    23  stays up to date and allows you to think through the problem at a high level before you get lost in the weeds of 
    24  coding.
    25  
    26  ## Update the tests
    27  
    28  We also recommend updating the automated tests *before* updating any code (see [Test Driven 
    29  Development](https://en.wikipedia.org/wiki/Test-driven_development)). That means you add or update a test case, 
    30  verify that it's failing with a clear error message, and *then* make the code changes to get that test to pass. This 
    31  ensures the tests stay up to date and verify all the functionality in this Module, including whatever new 
    32  functionality you're adding in your contribution. Check out the [tests](https://github.com/hashicorp/terraform-aws-consul/tree/master/test) folder for instructions on running the 
    33  automated tests. 
    34  
    35  ## Update the code
    36  
    37  At this point, make your code changes and use your new test case to verify that everything is working. As you work,
    38  keep in mind two things:
    39  
    40  1. Backwards compatibility
    41  1. Downtime
    42  
    43  ### Backwards compatibility
    44  
    45  Please make every effort to avoid unnecessary backwards incompatible changes. With Terraform code, this means:
    46  
    47  1. Do not delete, rename, or change the type of input variables.
    48  1. If you add an input variable, it should have a `default`.
    49  1. Do not delete, rename, or change the type of output variables.
    50  1. Do not delete or rename a module in the `modules` folder.
    51  
    52  If a backwards incompatible change cannot be avoided, please make sure to call that out when you submit a pull request, 
    53  explaining why the change is absolutely necessary. 
    54  
    55  ### Downtime
    56  
    57  Bear in mind that the Terraform code in this Module is used by real companies to run real infrastructure in 
    58  production, and certain types of changes could cause downtime. For example, consider the following:
    59  
    60  1. If you rename a resource (e.g. `aws_instance "foo"` -> `aws_instance "bar"`), Terraform will see that as deleting
    61     the old resource and creating a new one.
    62  1. If you change certain attributes of a resource (e.g. the `name` of an `aws_elb`), the cloud provider (e.g. AWS) may
    63     treat that as an instruction to delete the old resource and a create a new one. 
    64     
    65  Deleting certain types of resources (e.g. virtual servers, load balancers) can cause downtime, so when making code
    66  changes, think carefully about how to avoid that. For example, can you avoid downtime by using 
    67  [create_before_destroy](https://www.terraform.io/docs/configuration/resources.html#create_before_destroy)? Or via
    68  the `terraform state` command? If so, make sure to note this in our pull request. If  downtime cannot be avoided, 
    69  please make sure to call that out when you submit a pull request. 
    70  
    71  ## Create a pull request
    72  
    73  [Create a pull request](https://help.github.com/articles/creating-a-pull-request/) with your changes. Please make sure
    74  to include the following:
    75  
    76  1. A description of the change, including a link to your GitHub issue.
    77  1. The output of your automated test run, preferably in a [GitHub Gist](https://gist.github.com/). We cannot run 
    78     automated tests for pull requests automatically due to [security 
    79     concerns](https://circleci.com/docs/fork-pr-builds/#security-implications), so we need you to manually provide this 
    80     test output so we can verify that everything is working.
    81  1. Any notes on backwards incompatibility or downtime.
    82  
    83  ## Merge and release   
    84  
    85  The maintainers for this repo will review your code and provide feedback. If everything looks good, they will merge the
    86  code and release a new version, which you'll be able to find in the [releases page](../../releases).