We would like to THANK YOU for considering contributing to KICS!
KICS is a true community project. It's built as an open source from day one, and anyone can find his own way to contribute to the project.
Within just minutes, you can start making a difference, by sharing your expertise with a community of thousands of security experts and software developers.
You're welcome to join our monthly community meetings
Good news! You don't have to contribute code. There are plenty of ways you can contribute to KICS project:
- Reporting new bugs or issues
- Help triaging issues
- Improving and translating the documentation
- Volunteering to maintain the project
Code of Conduct¶
By participating and contributing to the project, you agree to uphold our Code of Conduct.
Follow the instructions below to setup local KICS development environment and push your changes.
- Fork the
kicsrepo on GitHub.
- Download and install Go 1.16 or higher from https://golang.org/dl/.
- Clone your fork locally:
- Create a branch for local development. Use succinct but descriptive name (prefix with feature/issue#-descriptive-name> or hotfix/issue#-descriptive-name):
- Make your changes locally.
- Validate your changes to reassure they meet project quality and contribution standards:
- Commit your changes and push your branch to GitHub: conventional commits messages
- Submit a pull request on GitHub website.
How to Contribute¶
Contributions are made to this repo via Issues and Pull Requests (PRs). A few general guidelines that cover both:
- Search for existing issues and pull requests before creating your own to avoid duplicates.
- PRs will only be accepted if associated with an issue (enhancement or bug) that has been submitted and reviewed/labeled as accepted.
- We will work hard to make sure issues that are raised are handled in a timely manner.
Issues should be used to report problems with the solution / source code, request a new feature, or to discuss potential changes before a PR is created. When you create a new Issue, a template will be loaded that will guide you through collecting and providing the information we need to investigate.
If you find an Issue that addresses the problem you're having, please add your own reproduction information to the existing issue rather than creating a new one. Adding a reaction can also help by indicating to our maintainers that a particular problem is affecting more than just the reporter.
Pull Requests (PRs) are always welcome and can be a quick way to get your fix or improvement slated for the next release. In general, PRs should:
- Only fix/add the functionality in question or address code style issues, not both.
- Ensure all necessary details are provided and adhered to.
- Add unit or integration tests for fixed or changed functionality (if a test suite already exists) or specify steps taken to ensure changes were tested and functionality works as expected.
- Address a single concern in the least number of changed lines as possible.
- Include documentation in the repo or Provide additional comments in Markdown comments that should be pulled/reflected in GitHub Wiki for the given project.
- Be accompanied by a complete Pull Request template (loaded automatically when a PR is created).
For changes that address core functionality or would require breaking changes (e.g. a major release), please open an Issue to discuss your proposal first.
Pull Request Guidelines¶
Before you submit a pull request, please reassure that it meets these guidelines:
- All validations and tests passed locally.
- The pull request includes tests.
- The relevant docs are updated, whether you're pushing new functionality or updating a query.
- The pull request title should follow conventional commit messages:
(<scope>) is optional
feat - A new feature (example scopes: engine, parser, flags, query) fix - A bug fix docs - Documentation only changes, (example scopes: catalog, guides, platforms, architecture) test - Adding missing tests or correcting existing tests (example scopes: unit, e2e) ci - Changes to our CI configuration files and scripts (example scopes: ghactions, linters) chore - Other changes that don't modify src or test files build - Changes that affect the build system or external dependencies (example scope: makefile) style - Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) refactor - A code change that neither fixes a bug nor adds a feature perf - A code change that improves performance revert - Reverts a previous commit
build(makefile): enhance make clean task
The following templates will be used when creating a new issue:
- Enhancement/Feature Request Template
- New (Approved) Feature Template
- Query Template
- Bug Report Template
And become one of our top contributors!
Special thanks to Lior Kaplan from Kaplan Open Source Consulting for his assistance in creating KICS.
The people listed below had made a huge contribution to KICS.
- Ruben Silva
- Rafaela Soares
- João Martins
- Joel Carvalho
- Pedro Mimoso
- Nuno Araújo
- Fábio Gonçalves
- Mariana Carvalho
- Jorge Cruz
- João Oliveira
- Diogo Lemos
- Alex Roichman
- Adar Weidman
- Eli Trop
- Joel Sousa
- Sónia Antão
- Catarina Araújo
- Pedro Pereira
- Samuel Ferreira
- Rui Gomes
- Rogério Peixoto
- João Reigota
- Felipe Avelar
- Nuno Oliveira
- Mark Mishaev
- Igor Markov
- Ori Bendet
- Erez Yalon
Thank you all!