arno
/
kube-bench
mirror of https://github.com/aquasecurity/kube-bench.git
1
0
Fork 0
Code Issues Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '9a950d2d9a'
${ noResults }
kube-bench/CONTRIBUTING.md

2.1 KiB
Raw Blame History

Thank you for taking an interest in contributing to kube-bench !

Issues

  • Feel free to open an issue for any reason as long as you make it clear if the issue is about a bug/feature/question/comment.
  • Please spend some 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, along with any relevant technical information.
  • For questions and bug reports, please include the following information:
    • version of kube-bench you are running (from kube-bench version) along with 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 setting 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.
  2. We will not accept changes to LICENSE, NOTICE or CONTRIBUTING from outside the Aqua Security team. Please raise an Issue if you believe there is a problem with any of these files.
  3. Your PR is more likely to be accepted if it focuses on just one change.
  4. 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 start with "fix"/"add"/"improve"/"remove" are good examples.
  5. Please add the associated Issue in the PR description.
  6. There's no need to add or tag reviewers.
  7. 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).
  8. Please include a comment with the results before and after your change.
  9. 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!).