diff options
author | Alexandre Garand <alexandre.garand@fretlink.com> | 2019-08-09 16:51:13 +0200 |
---|---|---|
committer | Alexandre Garand <alexandre.garand@fretlink.com> | 2019-08-09 16:51:13 +0200 |
commit | b74d3065f299a1953e6d21e3d48d3ce0629bcaf7 (patch) | |
tree | 0ce1b8fd1a2b3ff7d427b567111f0732faa461ec /vendor/github.com/google/go-querystring/CONTRIBUTING.md | |
parent | ebf8436f01bcacb71e3c378f08b165dfd6dd90e6 (diff) | |
parent | 464a0a808240c83e365ddc7a4c52b82ecf9b76c4 (diff) | |
download | terraform-provider-statuscake-b74d3065f299a1953e6d21e3d48d3ce0629bcaf7.tar.gz terraform-provider-statuscake-b74d3065f299a1953e6d21e3d48d3ce0629bcaf7.tar.zst terraform-provider-statuscake-b74d3065f299a1953e6d21e3d48d3ce0629bcaf7.zip |
Merge branch 'add_ssl_tests' of github.com:alexandreFre/terraform-provider-statuscake
Diffstat (limited to 'vendor/github.com/google/go-querystring/CONTRIBUTING.md')
-rw-r--r-- | vendor/github.com/google/go-querystring/CONTRIBUTING.md | 67 |
1 files changed, 67 insertions, 0 deletions
diff --git a/vendor/github.com/google/go-querystring/CONTRIBUTING.md b/vendor/github.com/google/go-querystring/CONTRIBUTING.md new file mode 100644 index 0000000..51cf5cd --- /dev/null +++ b/vendor/github.com/google/go-querystring/CONTRIBUTING.md | |||
@@ -0,0 +1,67 @@ | |||
1 | # How to contribute # | ||
2 | |||
3 | We'd love to accept your patches and contributions to this project. There are | ||
4 | a just a few small guidelines you need to follow. | ||
5 | |||
6 | |||
7 | ## Contributor License Agreement ## | ||
8 | |||
9 | Contributions to any Google project must be accompanied by a Contributor | ||
10 | License Agreement. This is not a copyright **assignment**, it simply gives | ||
11 | Google permission to use and redistribute your contributions as part of the | ||
12 | project. | ||
13 | |||
14 | * If you are an individual writing original source code and you're sure you | ||
15 | own the intellectual property, then you'll need to sign an [individual | ||
16 | CLA][]. | ||
17 | |||
18 | * If you work for a company that wants to allow you to contribute your work, | ||
19 | then you'll need to sign a [corporate CLA][]. | ||
20 | |||
21 | You generally only need to submit a CLA once, so if you've already submitted | ||
22 | one (even if it was for a different project), you probably don't need to do it | ||
23 | again. | ||
24 | |||
25 | [individual CLA]: https://developers.google.com/open-source/cla/individual | ||
26 | [corporate CLA]: https://developers.google.com/open-source/cla/corporate | ||
27 | |||
28 | |||
29 | ## Submitting a patch ## | ||
30 | |||
31 | 1. It's generally best to start by opening a new issue describing the bug or | ||
32 | feature you're intending to fix. Even if you think it's relatively minor, | ||
33 | it's helpful to know what people are working on. Mention in the initial | ||
34 | issue that you are planning to work on that bug or feature so that it can | ||
35 | be assigned to you. | ||
36 | |||
37 | 1. Follow the normal process of [forking][] the project, and setup a new | ||
38 | branch to work in. It's important that each group of changes be done in | ||
39 | separate branches in order to ensure that a pull request only includes the | ||
40 | commits related to that bug or feature. | ||
41 | |||
42 | 1. Go makes it very simple to ensure properly formatted code, so always run | ||
43 | `go fmt` on your code before committing it. You should also run | ||
44 | [golint][] over your code. As noted in the [golint readme][], it's not | ||
45 | strictly necessary that your code be completely "lint-free", but this will | ||
46 | help you find common style issues. | ||
47 | |||
48 | 1. Any significant changes should almost always be accompanied by tests. The | ||
49 | project already has good test coverage, so look at some of the existing | ||
50 | tests if you're unsure how to go about it. [gocov][] and [gocov-html][] | ||
51 | are invaluable tools for seeing which parts of your code aren't being | ||
52 | exercised by your tests. | ||
53 | |||
54 | 1. Do your best to have [well-formed commit messages][] for each change. | ||
55 | This provides consistency throughout the project, and ensures that commit | ||
56 | messages are able to be formatted properly by various git tools. | ||
57 | |||
58 | 1. Finally, push the commits to your fork and submit a [pull request][]. | ||
59 | |||
60 | [forking]: https://help.github.com/articles/fork-a-repo | ||
61 | [golint]: https://github.com/golang/lint | ||
62 | [golint readme]: https://github.com/golang/lint/blob/master/README | ||
63 | [gocov]: https://github.com/axw/gocov | ||
64 | [gocov-html]: https://github.com/matm/gocov-html | ||
65 | [well-formed commit messages]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html | ||
66 | [squash]: http://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits | ||
67 | [pull request]: https://help.github.com/articles/creating-a-pull-request | ||