|
| 1 | +# Contributing |
| 2 | + |
| 3 | +Source Controller is [Apache 2.0 licensed](LICENSE) and accepts contributions |
| 4 | +via GitHub pull requests. This document outlines some of the conventions on |
| 5 | +to make it easier to get your contribution accepted. |
| 6 | + |
| 7 | +We gratefully welcome improvements to issues and documentation as well as to |
| 8 | +code. |
| 9 | + |
| 10 | +## Certificate of Origin |
| 11 | + |
| 12 | +By contributing to this project you agree to the Developer Certificate of |
| 13 | +Origin (DCO). This document was created by the Linux Kernel community and is a |
| 14 | +simple statement that you, as a contributor, have the legal right to make the |
| 15 | +contribution. No action from you is required, but it's a good idea to see the |
| 16 | +[DCO](DCO) file for details before you start contributing code to Source |
| 17 | +Controller. |
| 18 | + |
| 19 | +## Communications |
| 20 | + |
| 21 | +The project uses Slack: To join the conversation, simply join the |
| 22 | +[CNCF](https://slack.cncf.io/) Slack workspace and use the |
| 23 | +[#flux](https://cloud-native.slack.com/messages/flux/) channel. |
| 24 | + |
| 25 | +The developers use a mailing list to discuss development as well. |
| 26 | +Simply subscribe to [flux-dev on cncf.io](https://lists.cncf.io/g/cncf-flux-dev) |
| 27 | +to join the conversation (this will also add an invitation to your |
| 28 | +Google calendar for our [Flux |
| 29 | +meeting](https://docs.google.com/document/d/1l_M0om0qUEN_NNiGgpqJ2tvsF2iioHkaARDeh6b70B0/edit#)). |
| 30 | + |
| 31 | +### How to run the test suite |
| 32 | + |
| 33 | +You can run the unit tests by simply doing |
| 34 | + |
| 35 | +```bash |
| 36 | +make test |
| 37 | +``` |
| 38 | + |
| 39 | +## Acceptance policy |
| 40 | + |
| 41 | +These things will make a PR more likely to be accepted: |
| 42 | + |
| 43 | +- a well-described requirement |
| 44 | +- tests for new code |
| 45 | +- tests for old code! |
| 46 | +- new code and tests follow the conventions in old code and tests |
| 47 | +- a good commit message (see below) |
| 48 | +- all code must abide [Go Code Review Comments](https://github.com/golang/go/wiki/CodeReviewComments) |
| 49 | +- names should abide [What's in a name](https://talks.golang.org/2014/names.slide#1) |
| 50 | +- code must build on both Linux and Darwin, via plain `go build` |
| 51 | +- code should have appropriate test coverage and tests should be written |
| 52 | + to work with `go test` |
| 53 | + |
| 54 | +In general, we will merge a PR once one maintainer has endorsed it. |
| 55 | +For substantial changes, more people may become involved, and you might |
| 56 | +get asked to resubmit the PR or divide the changes into more than one PR. |
| 57 | + |
| 58 | +### Format of the Commit Message |
| 59 | + |
| 60 | +For Source Controller we prefer the following rules for good commit messages: |
| 61 | + |
| 62 | +- Limit the subject to 50 characters and write as the continuation |
| 63 | + of the sentence "If applied, this commit will ..." |
| 64 | +- Explain what and why in the body, if more than a trivial change; |
| 65 | + wrap it at 72 characters. |
| 66 | + |
| 67 | +The [following article](https://chris.beams.io/posts/git-commit/#seven-rules) |
| 68 | +has some more helpful advice on documenting your work. |
0 commit comments