|
| 1 | +# Contributing to the Project |
| 2 | + |
| 3 | +This document contains and defines the rules that have to be followed by any |
| 4 | +contributor to the project, in order for any change to be merged into the |
| 5 | +stable branches. |
| 6 | + |
| 7 | +## Workflow Guidelines |
| 8 | + |
| 9 | +### Branching Guidelines |
| 10 | + |
| 11 | +When branching, the branch name should have one of the following prefixes: |
| 12 | + |
| 13 | +* improvement/ |
| 14 | +* bugfix/ |
| 15 | +* feature/ |
| 16 | + |
| 17 | +Additionally, the branch name should also contain a reference to the issue |
| 18 | +being tackled. For example, a branch tackling issue 123 introducing the new |
| 19 | +feature FooBar might be named `feature/GH-123-add-shiny-new-feature-FooBar`. |
| 20 | + |
| 21 | + |
| 22 | +### Committing Guidelines |
| 23 | + |
| 24 | +No restrictions are placed at this time on individual commits passing in the |
| 25 | +CI and/or maintaining full functionality of the repository. |
| 26 | + |
| 27 | +Commit messages should: |
| 28 | + |
| 29 | +* have a short (< 50 characters) summary as title |
| 30 | +* contain more explanations, if necessary, in the body |
| 31 | +* contain a reference to the issue being tackled in the body |
| 32 | + |
| 33 | +A commit message should *not* contain a reference to the issue in the title. |
| 34 | + |
| 35 | +### Pull Request Guidelines |
| 36 | + |
| 37 | +Pull requests should contain in their body a reference to the GitHub issue |
| 38 | +being targeted by the changeset introduced. |
| 39 | + |
| 40 | +### Signing your work |
| 41 | + |
| 42 | +In order to contribute to the project, you must sign your work. By signing your |
| 43 | +work, you certify to the statements set out in the Developer Certificate of |
| 44 | +Origin below (from |
| 45 | +[developercertificate.org](http://developercertificate.org/)): |
| 46 | + |
| 47 | +``` |
| 48 | +Developer Certificate of Origin |
| 49 | +Version 1.1 |
| 50 | +
|
| 51 | +Copyright (C) 2004, 2006 The Linux Foundation and its contributors. |
| 52 | +1 Letterman Drive |
| 53 | +Suite D4700 |
| 54 | +San Francisco, CA, 94129 |
| 55 | +
|
| 56 | +Everyone is permitted to copy and distribute verbatim copies of this |
| 57 | +license document, but changing it is not allowed. |
| 58 | +
|
| 59 | +
|
| 60 | +Developer's Certificate of Origin 1.1 |
| 61 | +
|
| 62 | +By making a contribution to this project, I certify that: |
| 63 | +
|
| 64 | +(a) The contribution was created in whole or in part by me and I |
| 65 | + have the right to submit it under the open source license |
| 66 | + indicated in the file; or |
| 67 | +
|
| 68 | +(b) The contribution is based upon previous work that, to the best |
| 69 | + of my knowledge, is covered under an appropriate open source |
| 70 | + license and I have the right under that license to submit that |
| 71 | + work with modifications, whether created in whole or in part |
| 72 | + by me, under the same open source license (unless I am |
| 73 | + permitted to submit under a different license), as indicated |
| 74 | + in the file; or |
| 75 | +
|
| 76 | +(c) The contribution was provided directly to me by some other |
| 77 | + person who certified (a), (b) or (c) and I have not modified |
| 78 | + it. |
| 79 | +
|
| 80 | +(d) I understand and agree that this project and the contribution |
| 81 | + are public and that a record of the contribution (including all |
| 82 | + personal information I submit with it, including my sign-off) is |
| 83 | + maintained indefinitely and may be redistributed consistent with |
| 84 | + this project or the open source license(s) involved. |
| 85 | +``` |
| 86 | + |
| 87 | +Signing your work is easy. Just add the following line at the end of each of |
| 88 | +your commit messages. You must use your real name in your sign-off. |
| 89 | + |
| 90 | +``` |
| 91 | +Signed-off-by: Jane Doe <jane.doe@email.com> |
| 92 | +``` |
| 93 | + |
| 94 | +If your `user.name` and `user.email` are set in your git configs, you can sign |
| 95 | +each commit automatically by using the `git commit -s` command. |
| 96 | + |
| 97 | +Note that contributors employed by Scality are considered to sign every commit |
| 98 | +by virtue of their contract with Scality. |
| 99 | + |
| 100 | +## Reporting an issue |
| 101 | + |
| 102 | +This project uses Github issues to manage the issues. |
| 103 | + |
| 104 | +Before creating an issue: |
| 105 | + |
| 106 | +1. upgrade the operator to the latest supported release version, and check whether your bug is still present, |
| 107 | +2. ensure the operator version is supported by the PowerDNS version you are using, |
| 108 | +3. have a look in the opened issues if your problem is already known/tracked, and possibly contribute to the thread with your own information. |
| 109 | + |
| 110 | +If none of the above was met, open an issue directly in Github, select the appropriate issue template and fill-in each section when applicable. |
| 111 | + |
| 112 | +## Testing & Linting |
| 113 | + |
| 114 | +Run tests and lint the code: |
| 115 | +```go |
| 116 | +go test -v ./... |
| 117 | +golangci-lint run |
| 118 | +``` |
0 commit comments