Merge pull request #5 from dholbach/add-contributing

Add general CONTRIBUTING information

CONTRIBUTING.md

@@ -0,0 +1,76 @@
+# Contributing
+
+> **Note:** In this document we explain the general communication
+> channels and contribution standards for the entire Flux project.
+
+Flux is [Apache 2.0 licensed](https://github.com/fluxcd/flux2/blob/main/LICENSE) and
+accepts contributions via GitHub pull requests. This document outlines
+some of the conventions on to make it easier to get your contribution
+accepted.
+
+We gratefully welcome improvements to issues and documentation as well as to
+code.
+
+## Certificate of Origin
+
+By contributing to this project you agree to the Developer Certificate of
+Origin (DCO). This document was created by the Linux Kernel community and is a
+simple statement that you, as a contributor, have the legal right to make the
+contribution.
+
+We require all commits to be signed. By signing off with your signature, you
+certify that you wrote the patch or otherwise have the right to contribute the
+material by the rules of the [DCO](DCO):
+
+`Signed-off-by: Jane Doe <[email protected]>`
+
+The signature must contain your real name
+(sorry, no pseudonyms or anonymous contributions)
+If your `user.name` and `user.email` are configured in your Git config,
+you can sign your commit automatically with `git commit -s`.
+
+## Communications
+
+For realtime communications we use Slack: To join the conversation, simply
+join the [CNCF](https://slack.cncf.io/) Slack workspace and use the
+[#flux-contributors](https://cloud-native.slack.com/messages/flux-contributors/) channel.
+
+To discuss ideas and specifications we use [Github
+Discussions](https://github.com/fluxcd/flux2/discussions).
+
+For announcements we use a mailing list as well. Simply subscribe to
+[flux-dev on cncf.io](https://lists.cncf.io/g/cncf-flux-dev)
+to join the conversation (there you can also add calendar invites
+to your Google calendar for our [Flux
+meeting](https://docs.google.com/document/d/1l_M0om0qUEN_NNiGgpqJ2tvsF2iioHkaARDeh6b70B0/view)).
+
+## Acceptance policy
+
+These things will make a PR more likely to be accepted:
+
+- a well-described requirement
+- tests for new code
+- tests for old code!
+- new code and tests follow the conventions in old code and tests
+- a good commit message (see below)
+- all code must abide [Go Code Review Comments](https://github.com/golang/go/wiki/CodeReviewComments)
+- names should abide [What's in a name](https://talks.golang.org/2014/names.slide#1)
+- code must build on both Linux and Darwin, via plain `go build`
+- code should have appropriate test coverage and tests should be written
+  to work with `go test`
+
+In general, we will merge a PR once one maintainer has endorsed it.
+For substantial changes, more people may become involved, and you might
+get asked to resubmit the PR or divide the changes into more than one PR.
+
+### Format of the Commit Message
+
+For the GitOps Toolkit controllers we prefer the following rules for good commit messages:
+
+- Limit the subject to 50 characters and write as the continuation
+  of the sentence "If applied, this commit will ..."
+- Explain what and why in the body, if more than a trivial change;
+  wrap it at 72 characters.
+
+The [following article](https://chris.beams.io/posts/git-commit/#seven-rules)
+has some more helpful advice on documenting your work.