Skip to content

Latest commit

 

History

History
85 lines (65 loc) · 4.96 KB

CONTRIBUTING.md

File metadata and controls

85 lines (65 loc) · 4.96 KB
Raw

Contributing

Welcome! We're excited you want to take part in the CrowdStrike community!

Please review this document for details regarding getting started with your first contribution, tools you'll need to install as a developer, and our development and Pull Request process. If you have any questions, please let us know by posting your question in the discussion board.

Table of Contents

Code of Conduct

Please refer to CrowdStrike's general Code of Conduct and contribution guidelines.

How you can contribute

Pull Requests

All code changes should be submitted via a Pull Request targeting the main branch. We are not assuming that every merged PR creates a release, so we will not be automatically creating new SemVer tags as a side effect of merging your Pull Request. Instead, we will manually tag new releases when required.

License

When you submit code changes, your submissions are understood to be under the same Unlicense license that covers the project. If this is a concern, contact the maintainers before contributing.

Breaking changes

In an effort to maintain backwards compatibility, we thoroughly unit test every Pull Request for all versions of PowerShell we support. These unit tests are intended to catch general programmatic errors, possible vulnerabilities and potential breaking changes.

Please fully document unit testing performed within your Pull Request. If you did not specify "Breaking Change" on the punch list in the description, and the change is identified as possibly breaking, this may delay or prevent approval of your PR.

Code Coverage

While we feel like achieving and maintaining 100% code coverage is often an untenable goal with diminishing returns, any changes that reduce code coverage will receive pushback. We don't want people to spend days trying to bump coverage from 97% to 98%, often at the expense of code clarity, but that doesn't mean that we're okay with making things worse.

Commit Message Formatting and Hygiene

We use Conventional Commits formatting for commit messages, which we feel leads to a much more informative change history. Please familiarize yourself with that specification and format your commit messages accordingly.

Another aspect of achieving a clean, informative commit history is to avoid "noise" in commits. Ideally, condense your changes to a single commit with a well-written Conventional Commits message before submitting a PR. In the rare case that a single PR is introducing more than one change, each change should be a single commit with its own well-written message.

Pull Request template

Please use the pull request template provided, making sure the following details are included in your request:

  • Is this a breaking change?
  • Are all new or changed code paths covered by unit testing?
  • A complete listing of issues addressed or closed with this change.
  • A complete listing of any enhancements provided by this change.
  • Any usage details developers may need to make use of this new functionality.
    • Does additional documentation need to be developed beyond what is listed in your Pull Request?
  • Any other salient points of interest.

Approval / Merging

All Pull Requests must be approved by at least one maintainer. Once approved, a maintainer will perform the merge and execute any backend processes related to package deployment. At this time, contributors do not have the ability to merge to the main branch.