Add contributing doc

Signed-off-by: Stefan Prodan <stefan.prodan@gmail.com>

CONTRIBUTING.md

@@ -0,0 +1,114 @@
+# Contributing
+
+Helm Controller is [Apache 2.0 licensed](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 <jane.doe@example.com>`
+
+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
+
+The project uses Slack: To join the conversation, simply join the
+[CNCF](https://slack.cncf.io/) Slack workspace and use the
+[#flux](https://cloud-native.slack.com/messages/flux/) channel.
+
+The developers use a mailing list to discuss development as well.
+Simply subscribe to [flux-dev on cncf.io](https://lists.cncf.io/g/cncf-flux-dev)
+to join the conversation (this will also add an invitation to your
+Google calendar for our [Flux
+meeting](https://docs.google.com/document/d/1l_M0om0qUEN_NNiGgpqJ2tvsF2iioHkaARDeh6b70B0/edit#)).
+
+### How to run the test suite
+
+Prerequisites:
+* go >= 1.13
+* kubebuilder >= 2.3
+* kustomize >= 3.1
+
+You can run the unit tests by simply doing
+
+```bash
+make test
+```
+
+### How to run the controller locally
+
+Install flux on your test cluster:
+
+```sh
+flux install
+```
+
+Scale the in-cluster controller to zero:
+
+```sh
+kubectl -n flux-system scale deployment/helm-controller --replicas=0
+```
+
+Port forward to source-controller artifacts server:
+
+```sh
+kubectl -n flux-system port-forward svc/source-controller 8080:80
+```
+
+Export the local address as `SOURCE_CONTROLLER_LOCALHOST`:
+
+```sh
+export SOURCE_CONTROLLER_LOCALHOST=localhost:8080
+```
+
+Run the controller locally:
+
+```sh
+make run
+```
+
+## 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 Helm Controller 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.