|
| 1 | +# Contributing to terraform-plugin-go |
| 2 | + |
| 3 | +**First:** if you're unsure or afraid of _anything_, just ask |
| 4 | +or submit the issue describing the problem you're aiming to solve. |
| 5 | + |
| 6 | +Any bug fix or feature has to be considered in the context of the wider |
| 7 | +Terraform ecosystem. This is great, as your contribution can have a big |
| 8 | +positive impact, but we have to assess potential negative impact too (e.g. |
| 9 | +breaking existing providers which may not use a new feature). |
| 10 | + |
| 11 | +To provide some safety to the wider provider ecosystem, we strictly follow |
| 12 | +[semantic versioning](https://semver.org/) and any changes that we consider |
| 13 | +breaking changes will only be released as part of major releases. **Note:** |
| 14 | +while we're on v0, breaking changes will be accepted during minor releases. |
| 15 | + |
| 16 | +## Table of Contents |
| 17 | + |
| 18 | + - [I just have a question](#i-just-have-a-question) |
| 19 | + - [I want to report a vulnerability](#i-want-to-report-a-vulnerability) |
| 20 | + - [New Issue](#new-issue) |
| 21 | + - [New Pull Request](#new-pull-request) |
| 22 | + |
| 23 | +## I just have a question |
| 24 | + |
| 25 | +> **Note:** We use GitHub for tracking bugs and feature requests related to |
| 26 | +> terraform-plugin-go. |
| 27 | +
|
| 28 | +For questions, please see relevant channels at |
| 29 | +https://www.terraform.io/community.html |
| 30 | + |
| 31 | +## I want to report a vulnerability |
| 32 | + |
| 33 | +Please disclose security vulnerabilities responsibly by following the procedure |
| 34 | +described at https://www.hashicorp.com/security#vulnerability-reporting |
| 35 | + |
| 36 | +## New Issue |
| 37 | + |
| 38 | +We welcome issues of all kinds, including feature requests, bug reports, or |
| 39 | +documentation suggestions. Below are guidelines for well-formed issues of each |
| 40 | +type. |
| 41 | + |
| 42 | +### Bug Reports |
| 43 | + |
| 44 | + - [ ] **Test against latest release**: Make sure you test against the latest |
| 45 | + avaiable version of both Terraform and terraform-plugin-go. It is possible |
| 46 | + we already fixed the bug you're experiencing. |
| 47 | + |
| 48 | + - [ ] **Search for duplicates**: It's helpful to keep bug reports consolidated |
| 49 | + to one thread, so do a quick search on existing bug reports to check if |
| 50 | + anybody else has reported the same thing. You can scope searches by the |
| 51 | + label `bug` to help narrow things down. |
| 52 | + |
| 53 | + - [ ] **Include steps to reproduce**: Provide steps to reproduce the issue, |
| 54 | + along with code examples (both HCL and Go, where applicable) and/or real |
| 55 | + code, so we can try to reproduce it. Without this, it makes it much harder |
| 56 | + (sometimes impossible) to fix the issue. |
| 57 | + |
| 58 | +### Feature Requests |
| 59 | + |
| 60 | + - [ ] **Search for possible duplicate requests**: It's helpful to keep |
| 61 | + requests consolidated to one thread, so do a quick search on existing |
| 62 | + requests to check if anybody else has requested the same thing. You can |
| 63 | + scope searches by the label `enhancement` to help narrow things down. |
| 64 | + |
| 65 | + - [ ] **Include a use case description**: In addition to describing the |
| 66 | + behavior of the feature you'd like to see added, it's helpful to also lay |
| 67 | + out the reason why the feature would be important and how it would benefit |
| 68 | + the wider Terraform ecosystem. A use case in the context of 1 provider is |
| 69 | + good, a use case in the context of many providers is better. |
| 70 | + |
| 71 | +### Documentation Suggestions |
| 72 | + |
| 73 | + - [ ] **Search for possible duplicate suggestions**: It's helpful to keep |
| 74 | + suggestions consolidated to one thread, so do a quick search on existing |
| 75 | + issues to check if anybody else has suggested the same thing. You can scope |
| 76 | + searches by the label `documentation` to help narrow things down. |
| 77 | + |
| 78 | + - [ ] **Describe the questions you're hoping the documentation will answer**: |
| 79 | + It's very helpful when writing documentation to have specific questions like |
| 80 | + "what is required of the response to ApplyResourceChange?" in mind. This |
| 81 | + helps us ensure the documentation is targeted, specific, and framed in a |
| 82 | + useful way. |
| 83 | + |
| 84 | +## New Pull Request |
| 85 | + |
| 86 | +Thank you for contributing! |
| 87 | + |
| 88 | +We are happy to review pull requests without associated issues, but we highly |
| 89 | +recommend starting by describing and discussing your problem or feature and |
| 90 | +attaching use cases to an issue first before raising a pull request. |
| 91 | + |
| 92 | +- [ ] **Early validation of idea and implementation plan**: terraform-plugin-go |
| 93 | + is complicated enough that there are often several ways to implement |
| 94 | + something, each of which has different implications and tradeoffs. Working |
| 95 | + through a plan of attack with the team before you dive into implementation |
| 96 | + will help ensure that you're working in the right direction. |
| 97 | + |
| 98 | +- [ ] **Unit Tests**: It may go without saying, but every new patch should be |
| 99 | + covered by tests wherever possible. |
| 100 | + |
| 101 | +- [ ] **Integration Tests**: Not all tests are appropriate to surface as unit |
| 102 | + tests. We use |
| 103 | + [`terraform-provider-corner`](https://github.com/hashicorp/terraform-provider-corner) |
| 104 | + to gather use cases that get run as part of our test suite. These real-world |
| 105 | + test cases are run by an actual Terraform binary and help us verify that |
| 106 | + end-to-end behavior as observed by users is retained. We encourage |
| 107 | + contributors to add test cases to `terraform-provider-corner` when |
| 108 | + contributing new features or submitting bug fixes. We love to see links to |
| 109 | + `terraform-provider-corner` PRs from `terraform-plugin-go` PRs. |
| 110 | + |
| 111 | +- [ ] **Go Modules**: We use [Go |
| 112 | + Modules](https://github.com/golang/go/wiki/Modules) to manage and version all |
| 113 | + our dependencies. Please make sure that you reflect dependency changes in |
| 114 | + your pull requests appropriately (e.g. `go get`, `go mod tidy` or other |
| 115 | + commands). Where possible it is better to raise a separate pull request with |
| 116 | + just dependency changes as it's easier to review such PR(s). |
| 117 | + |
| 118 | +### Cosmetic changes, code formatting, and typos |
| 119 | + |
| 120 | +In general we do not accept PRs containing only the following changes: |
| 121 | + |
| 122 | + - Correcting spelling or typos |
| 123 | + - Code formatting, including whitespace |
| 124 | + - Other cosmetic changes that do not affect functionality |
| 125 | + |
| 126 | +While we appreciate the effort that goes into preparing PRs, there is always a |
| 127 | +tradeoff between benefit and cost. The costs involved in accepting such |
| 128 | +contributions include the time taken for thorough review, the noise created in |
| 129 | +the git history, and the increased number of GitHub notifications that |
| 130 | +maintainers must attend to. |
| 131 | + |
| 132 | +#### Exceptions |
| 133 | + |
| 134 | +We belive that one should "leave the campsite cleaner than you found it", so |
| 135 | +you are welcome to clean up cosmetic issues in the neighbourhood when |
| 136 | +submitting a patch that makes functional changes or fixes. |
0 commit comments