|
1 | 1 | ## Contribution Guidelines |
2 | 2 |
|
| 3 | +You'll find below general guidelines, which mostly correspond to standard practices for open sourced repositories. |
| 4 | + |
| 5 | +>**TL;DR** |
| 6 | +> |
| 7 | +> If you're already an experience go developer on github, then you should just feel at home with us |
| 8 | +> and you may well skip the rest of this document. |
| 9 | +> |
| 10 | +> You'll essentially find the usual guideline for a go library project on github. |
| 11 | +
|
| 12 | +These guidelines are general to all libraries published on github by the `go-openapi` organization. |
| 13 | + |
| 14 | +You'll find more detailed (or repo-specific) instructions in the [maintainer's docs](../docs). |
| 15 | + |
| 16 | +## Questions & Issues |
| 17 | + |
| 18 | +### Asking questions |
| 19 | + |
| 20 | +You may inquire about anything about this library by reporting a "Question" issue on github. |
| 21 | + |
| 22 | +### Reporting issues |
| 23 | + |
| 24 | +Reporting a problem with our libraries _is_ a valuable contribution. |
| 25 | + |
| 26 | +You can do this on the github issues page of this repository. |
| 27 | + |
| 28 | +Please be as specific as possible when describing your issue. |
| 29 | + |
| 30 | +Whenever relevant, please provide information about your environment (go version, OS). |
| 31 | + |
| 32 | +Adding a code snippet to reproduce the issue is great, and as a big time saver for maintainers. |
| 33 | + |
| 34 | +### Triaging issues |
| 35 | + |
| 36 | +You can help triage issues which may include: |
| 37 | + |
| 38 | +* reproducing bug reports |
| 39 | +* asking for important information, such as version numbers or reproduction instructions |
| 40 | +* answering questions and sharing your insight in issue comments |
| 41 | + |
| 42 | +## Code contributions |
| 43 | + |
3 | 44 | ### Pull requests are always welcome |
4 | 45 |
|
5 | | -We are always thrilled to receive pull requests, and do our best to |
6 | | -process them as fast as possible. Not sure if that typo is worth a pull |
7 | | -request? Do it! We will appreciate it. |
| 46 | +We are always thrilled to receive pull requests, and we do our best to |
| 47 | +process them as fast as possible. |
| 48 | + |
| 49 | +Not sure if that typo is worth a pull request? Do it! We will appreciate it. |
| 50 | + |
| 51 | +If your pull request is not accepted on the first try, don't be discouraged! |
| 52 | +If there's a problem with the implementation, hopefully you received feedback on what to improve. |
| 53 | + |
| 54 | +If you have a lot of ideas or a lot of issues to solve, try to refrain a bit and post focused |
| 55 | +pull requests. |
| 56 | +Think that they must be reviewed by a maintainer and it is easy to lost track of things on big PRs. |
| 57 | + |
| 58 | +We're trying very hard to keep the go-openapi packages lean and focused. |
| 59 | +These packages constitute a toolkit: it won't do everything for everybody out of the box, |
| 60 | +but everybody can use it to do just about everything related to OpenAPI. |
| 61 | + |
| 62 | +This means that we might decide against incorporating a new feature. |
| 63 | + |
| 64 | +However, there might be a way to implement that feature *on top of* our libraries. |
| 65 | + |
| 66 | +### Environment |
8 | 67 |
|
9 | | -If your pull request is not accepted on the first try, don't be |
10 | | -discouraged! If there's a problem with the implementation, hopefully you |
11 | | -received feedback on what to improve. |
| 68 | +You just need a `go` compiler to be installed. No special tools are needed to work with our libraries. |
12 | 69 |
|
13 | | -We're trying very hard to keep go-swagger lean and focused. We don't want it |
14 | | -to do everything for everybody. This means that we might decide against |
15 | | -incorporating a new feature. However, there might be a way to implement |
16 | | -that feature *on top of* go-swagger. |
| 70 | +The go compiler version required is always the old stable (latest minor go version - 1). |
17 | 71 |
|
| 72 | +If you're already used to work with `go` you should already have everything in place. |
| 73 | + |
| 74 | +Although not required, you'll be certainly more productive with a local installation of `golangci-lint`, |
| 75 | +the meta-linter our CI uses. |
| 76 | + |
| 77 | +If you don't have it, you may install it like so: |
| 78 | + |
| 79 | +```sh |
| 80 | +go install github.com/golangci/golangci-lint/v2/cmd/golangci-lint@latest |
| 81 | +``` |
18 | 82 |
|
19 | 83 | ### Conventions |
20 | 84 |
|
21 | | -Fork the repo and make changes on your fork in a feature branch: |
| 85 | +#### Git flow |
| 86 | + |
| 87 | +Fork the repo and make changes to your fork in a feature branch. |
| 88 | + |
| 89 | +To submit a pull request, push your branch to your fork (e.g. `upstream` remote): |
| 90 | +github will propose to open a pull request on the original repository. |
| 91 | + |
| 92 | +Typically you'd follow some common naming conventions: |
22 | 93 |
|
23 | | -- If it's a bugfix branch, name it XXX-something where XXX is the number of the |
24 | | - issue |
25 | | -- If it's a feature branch, create an enhancement issue to announce your |
26 | | - intentions, and name it XXX-something where XXX is the number of the issue. |
| 94 | +- if it's a bugfix branch, name it `fix/XXX-something`where XXX is the number of the |
| 95 | + issue on github |
| 96 | +- if it's a feature branch, create an enhancement issue to announce your |
| 97 | + intentions, and name it `feature/XXX-something` where XXX is the number of the issue. |
27 | 98 |
|
28 | | -Submit unit tests for your changes. Go has a great test framework built in; use |
29 | | -it! Take a look at existing tests for inspiration. Run the full test suite on |
30 | | -your branch before submitting a pull request. |
| 99 | +> NOTE: we don't enforce naming conventions on branches: it's your fork after all. |
31 | 100 |
|
32 | | -Update the documentation when creating or modifying features. Test |
33 | | -your documentation changes for clarity, concision, and correctness, as |
34 | | -well as a clean documentation build. See ``docs/README.md`` for more |
35 | | -information on building the docs and how docs get released. |
| 101 | +#### Tests |
36 | 102 |
|
37 | | -Write clean code. Universally formatted code promotes ease of writing, reading, |
38 | | -and maintenance. Always run `gofmt -s -w file.go` on each changed file before |
39 | | -committing your changes. Most editors have plugins that do this automatically. |
| 103 | +Submit unit tests for your changes. |
| 104 | + |
| 105 | +Go has a great built-in test framework ; use it! |
| 106 | + |
| 107 | +Take a look at existing tests for inspiration, and run the full test suite on your branch |
| 108 | +before submitting a pull request. |
| 109 | + |
| 110 | +Our CI measures test coverage and the test coverage of every patch. |
| 111 | +Although not a blocking step - because there are so many special cases - |
| 112 | +this is an indicator that maintainers consider when approving a PR. |
| 113 | + |
| 114 | +Please try your best to cover about 80% of your patch. |
| 115 | + |
| 116 | +#### Code style |
| 117 | + |
| 118 | +You may read our stance on code style [there](../docs/STYLE.md). |
| 119 | + |
| 120 | +#### Documentation |
| 121 | + |
| 122 | +Don't forget to update the documentation when creating or modifying features. |
| 123 | + |
| 124 | +Most documentation for this library is directly found in code as comments for godoc. |
| 125 | + |
| 126 | +The documentation for the go-openapi packages is published on the public go docs site: |
| 127 | + |
| 128 | +<https://pkg.go.dev/github.com/go-openapi/jsonpointer> |
| 129 | + |
| 130 | +Check your documentation changes for clarity, concision, and correctness. |
| 131 | + |
| 132 | +If you want to assess the rendering of your changes when published to `pkg.go.dev`, you may |
| 133 | +want to install the `pkgsite` tool proposed by `golang.org`. |
| 134 | + |
| 135 | +```sh |
| 136 | +go install golang.org/x/pkgsite/cmd/pkgsite@latest |
| 137 | +``` |
| 138 | + |
| 139 | +Then run on the repository folder: |
| 140 | +```sh |
| 141 | +pkgsite . |
| 142 | +``` |
| 143 | + |
| 144 | +This wil run a godoc server locally where you may see the documentation generated from your local repository. |
| 145 | + |
| 146 | +#### Commit messages |
40 | 147 |
|
41 | 148 | Pull requests descriptions should be as clear as possible and include a |
42 | 149 | reference to all the issues that they address. |
43 | 150 |
|
44 | 151 | Pull requests must not contain commits from other users or branches. |
45 | 152 |
|
46 | | -Commit messages must start with a capitalized and short summary (max. 50 |
47 | | -chars) written in the imperative, followed by an optional, more detailed |
48 | | -explanatory text which is separated from the summary by an empty line. |
| 153 | +Commit messages are not required to follow the "conventional commit" rule, but it's certainly a good |
| 154 | +thing to follow this guidelinea (e.g. "fix: blah blah", "ci: did this", "feat: did that" ...). |
| 155 | + |
| 156 | +The title in your commit message is used directly to produce our release notes: try to keep them neat. |
| 157 | + |
| 158 | +The commit message body should detail your changes. |
| 159 | + |
| 160 | +If an issue should be closed by a commit, please add this reference in the commit body: |
| 161 | + |
| 162 | +``` |
| 163 | +* fixes #{issue number} |
| 164 | +``` |
| 165 | + |
| 166 | +#### Code review |
| 167 | + |
| 168 | +Code review comments may be added to your pull request. |
| 169 | + |
| 170 | +Discuss, then make the suggested modifications and push additional commits to your feature branch. |
| 171 | + |
| 172 | +Be sure to post a comment after pushing. The new commits will show up in the pull |
| 173 | +request automatically, but the reviewers will not be notified unless you comment. |
| 174 | + |
| 175 | +Before the pull request is merged, |
| 176 | +**make sure that you squash your commits into logical units of work** |
| 177 | +using `git rebase -i` and `git push -f`. |
| 178 | + |
| 179 | +After every commit the test suite should be passing. |
49 | 180 |
|
50 | | -Code review comments may be added to your pull request. Discuss, then make the |
51 | | -suggested modifications and push additional commits to your feature branch. Be |
52 | | -sure to post a comment after pushing. The new commits will show up in the pull |
53 | | -request automatically, but the reviewers will not be notified unless you |
54 | | -comment. |
| 181 | +Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix. |
55 | 182 |
|
56 | | -Before the pull request is merged, make sure that you squash your commits into |
57 | | -logical units of work using `git rebase -i` and `git push -f`. After every |
58 | | -commit the test suite should be passing. Include documentation changes in the |
59 | | -same commit so that a revert would remove all traces of the feature or fix. |
| 183 | +#### Sign your work |
60 | 184 |
|
61 | | -Commits that fix or close an issue should include a reference like `Closes #XXX` |
62 | | -or `Fixes #XXX`, which will automatically close the issue when merged. |
| 185 | +The sign-off is a simple line at the end of your commit message, |
| 186 | +which certifies that you wrote it or otherwise have the right to |
| 187 | +pass it on as an open-source patch. |
63 | 188 |
|
64 | | -### Sign your work |
| 189 | +We require the simple DCO below with an email signing your commit. |
| 190 | +PGP-signed commit are greatly appreciated but not required. |
65 | 191 |
|
66 | | -The sign-off is a simple line at the end of the explanation for the |
67 | | -patch, which certifies that you wrote it or otherwise have the right to |
68 | | -pass it on as an open-source patch. The rules are pretty simple: if you |
69 | | -can certify the below (from |
| 192 | +The rules are pretty simple: if you can certify the below (from |
70 | 193 | [developercertificate.org](http://developercertificate.org/)): |
71 | 194 |
|
72 | 195 | ``` |
|
0 commit comments