|
| 1 | +# source{d} Contributing Guidelines |
| 2 | + |
| 3 | +source{d} projects accept contributions via GitHub pull requests. |
| 4 | +This document outlines some of the |
| 5 | +conventions on development workflow, commit message formatting, contact points, |
| 6 | +and other resources to make it easier to get your contribution accepted. |
| 7 | + |
| 8 | +## Certificate of Origin |
| 9 | + |
| 10 | +By contributing to this project you agree to the [Developer Certificate of |
| 11 | +Origin (DCO)](DCO). This document was created by the Linux Kernel community and is a |
| 12 | +simple statement that you, as a contributor, have the legal right to make the |
| 13 | +contribution. |
| 14 | + |
| 15 | +In order to show your agreement with the DCO you should include at the end of commit message, |
| 16 | +the following line: `Signed-off-by: John Doe <[email protected]>`, using your real name. |
| 17 | + |
| 18 | +This can be done easily using the [`-s`](https://github.com/git/git/blob/b2c150d3aa82f6583b9aadfecc5f8fa1c74aca09/Documentation/git-commit.txt#L154-L161) flag on the `git commit`. |
| 19 | + |
| 20 | + |
| 21 | + |
| 22 | +## Support Channels |
| 23 | + |
| 24 | +The official support channels, for both users and contributors, are: |
| 25 | + |
| 26 | +- GitHub issues: each repository has its own list of issues. |
| 27 | +- Slack: join the [source{d} Slack](https://join.slack.com/t/sourced-community/shared_invite/enQtMjc4Njk5MzEyNzM2LTFjNzY4NjEwZGEwMzRiNTM4MzRlMzQ4MmIzZjkwZmZlM2NjODUxZmJjNDI1OTcxNDAyMmZlNmFjODZlNTg0YWM) community. |
| 28 | + |
| 29 | +*Before opening a new issue or submitting a new pull request, it's helpful to |
| 30 | +search the project - it's likely that another user has already reported the |
| 31 | +issue you're facing, or it's a known issue that we're already aware of. |
| 32 | + |
| 33 | + |
| 34 | +## How to Contribute |
| 35 | + |
| 36 | +Pull Requests (PRs) are the main and exclusive way to contribute code to source{d} projects. |
| 37 | +In order for a PR to be accepted it needs to pass a list of requirements: |
| 38 | + |
| 39 | +- The contribution must be correctly explained with natural language and providing a minimum working example that reproduces it. |
| 40 | +- All PRs must be written idiomaticly: |
| 41 | + - for Go: formatted according to [gofmt](https://golang.org/cmd/gofmt/), and without any warnings from [go lint](https://github.com/golang/lint) nor [go vet](https://golang.org/cmd/vet/) |
| 42 | + - for other languages, similar constraints apply. |
| 43 | +- They should in general include tests, and those shall pass. |
| 44 | + - If the PR is a bug fix, it has to include a new unit test that fails before the patch is merged. |
| 45 | + - If the PR is a new feature, it has to come with a suite of unit tests, that tests the new functionality. |
| 46 | + - In any case, all the PRs have to pass the personal evaluation of at least one of the [maintainers](MAINTAINERS) of the project. |
| 47 | + |
| 48 | + |
| 49 | +### Format of the commit message |
| 50 | + |
| 51 | +Every commit message should describe what was changed, under which context and, if applicable, the GitHub issue it relates to: |
| 52 | + |
| 53 | +``` |
| 54 | +plumbing: packp, Skip argument validations for unknown capabilities. Fixes #623 |
| 55 | +``` |
| 56 | + |
| 57 | +The format can be described more formally as follows: |
| 58 | + |
| 59 | +``` |
| 60 | +<package>: <subpackage>, <what changed>. [Fixes #<issue-number>] |
| 61 | +``` |
0 commit comments