Skip to content

Latest commit

 

History

History
39 lines (22 loc) · 3.3 KB

CONTRIBUTING.md

File metadata and controls

39 lines (22 loc) · 3.3 KB
Raw

Contributing to Security Onion

Questions, suggestions, and general comments

  • Security Onion uses GitHub's Discussions to provide a forum where the community and developers can interact as well as ask and answer questions.

Reporting a bug

  • The primary place to report unexpected behavior or possible bugs is the repo's Discussions forum.

  • If you are familiar with the current version of Security Onion and are confident you've discovered a bug, first ensure there is not already an issue present by searching the open issues. If there is, a thumbs up 👍 is a great way to show this bug is affecting you too.

  • If an issue doesn't exist, open a new one, following the directions in the issue template. This means including:

    • System information and how Security Onion was installed
    • Log files relevant to the bug report
    • Reproduction steps

Contributing code

  • All commits must be signed with a valid key that has been added to your GitHub account. Each commit should have the "Verified" tag when viewed on GitHub as shown below:

  • If an issue does not already exist for the bug or feature for which you are submitting a pull request, create one with the relevant prefix. (FIX: for bug fixes, FEATURE: for new features.)

  • Link the PR to the related issue, either using keywords in the PR description, or manually.

  • Pull requests should be opened against the dev branch of this repo, and should clearly describe the problem and solution.

  • Be sure you have tested your changes and are confident they will not break other parts of the product.

  • See this document's code styling and conventions section below to be sure your PR fits our code requirements prior to submitting.

Code style and conventions

  • Keep code DRY. For example, Bash code used by multiple scripts will likely best be added to so-common.

  • All new Bash code should pass ShellCheck analysis. Where errors can be safely ignored, the relevant disable directive should be accompanied by a brief explanation as to why the error is being ignored.

  • Ensure all YAML (this includes Salt states and pillars) is properly formatted. The spec for YAML v1.2 can be found here, however there are numerous online resources with simpler descriptions of its formatting rules.