add contribution guidelines (#454)

CONTRIBUTING.md

@@ -0,0 +1,23 @@
+Thank you for taking interest in contributing to kube-bench !
+
+## Issues
+
+- Feel free to open issues for any reason as long as you make it clear if this issue is about a bug/feature/question/comment.
+- Please spend a small amount of time giving due diligence to the issue tracker. Your issue might be a duplicate. If it is, please add your comment to the existing issue.
+- Remember users might be searching for your issue in the future, so please give it a meaningful title to help others.
+- The issue should clearly explain the reason for opening, the proposal if you have any, and any technical information that's relevant.
+- For questions and bug reports, please include the following information:
+  - version of kube-bench you are running (from kube-bench version) and the command line options you are using.
+  - version of Kubernetes you are running (from kubectl version or oc version for Openshift).
+  - Verbose log output, by seting the `-v 10` command line option.
+
+## Pull Requests
+
+1. Every Pull Request should have an associated Issue unless you are fixing a trivial documentation issue.
+1. Your PR is more likely to be accepted if it focuses on just one change.
+1. Describe what the PR does. There's no convention enforced, but please try to be concise and descriptive. Treat the PR description as a commit message. Titles that starts with "fix"/"add"/"improve"/"remove" are good examples.
+1. Please add the associated Issue in the PR description.
+1. There's no need to add or tag reviewers.
+1. If a reviewer commented on your code, or asked for changes, please remember to mark the discussion as resolved after you address it. PRs with unresolved issues should not be merged (even if the comment is unclear or requires no action from your side).
+1. Please include a comment with the results before and after your change.
+1. Your PR is more likely to be accepted if it includes tests (We have not historically been very strict about tests, but we would like to improve this!).

README.md

@@ -220,36 +220,3 @@ Next you'll have to build the kube-bench docker image using `make build-docker`,
 Finally we can use the `make kind-run` target to run the current version of kube-bench in the cluster and follow the logs of pods created. (Ctrl+C to exit)
 
 Everytime you want to test a change, you'll need to rebuild the docker image and push it to cluster before running it again. ( `make build-docker kind-push kind-run` )
-
-# GitHub Issues
-
-## Bugs
-
-If you think you have found a bug please follow the instructions below.
-
-- Please spend a small amount of time giving due diligence to the issue tracker. Your issue might be a duplicate.
-- Open a [new issue](https://github.com/aquasecurity/kube-bench/issues/new) if a duplicate doesn't already exist.
-- Note the version of kube-bench you are running (from `kube-bench version`) and the command line options you are using.
-- Note the version of kubernetes you are running (from `kubectl version` or `oc version` for Openshift).
-- Set `-v 10` command line option and save the log output. Please paste this into your issue.
-- Remember users might be searching for your issue in the future, so please give it a meaningful title to help others.
-
-## Features
-
-We also use the GitHub issue tracker to track feature requests. If you have an idea to make kube-bench even more awesome follow the steps below.
-
-- Open a [new issue](https://github.com/aquasecurity/kube-bench/issues/new).
-- Remember users might be searching for your issue in the future, so please give it a meaningful title to helps others.
-- Clearly define the use case, using concrete examples. For example: I type `this` and kube-bench does `that`.
-- If you would like to include a technical design for your feature please feel free to do so.
-
-## Pull Requests 
-
-We welcome pull requests! 
-
-- Your PR is more likely to be accepted if it focuses on just one change.
-- Please include a comment with the results before and after your change. 
-- Your PR is more likely to be accepted if it includes tests. (We have not historically been very strict about tests, but we would like to improve this!). 
-- You're welcome to submit a draft PR if you would like early feedback on an idea or an approach. 
-- Happy coding!
-