docs: add CONTRIBUTING.md (#2)

Author: jtieri

CONTRIBUTING.md

@@ -0,0 +1,53 @@
+# Contributor Guidelines
+
+## Introduction 
+
+Welcome to the Strangelove contributor guidelines. We are excited to have you here and look forward to your contributions!
+Contributors are expected to adhere to the guidelines outlined in this document as well as our [code of conduct](./CODE_OF_CONDUCT.md).
+
+##  Contributing
+
+There are many ways to contribute, from writing tutorials or blog posts, improving the documentation, 
+submitting bug reports and feature requests, or writing code which can be incorporated into the project itself.
+
+### Bug Reports
+
+First thing to note is that if you believe you have discovered a security vulnerability *DO NOT* use the public issue tracker. 
+Please read our [security policy](./SECURITY.md) for more information on reporting security vulnerabilities.
+
+When creating a bug report, please use the [template](./.github/ISSUE_TEMPLATE/bug_report.yml) and include as much 
+detail as possible. At a minimum be sure to include the following:
+- What you were trying to do
+- How the bug can be reproduced
+- What you expected to happen
+- What version of the software you were using
+
+### Feature Requests & Enhancements
+
+Feature requests and other enhancements can be made using the [template](./.github/ISSUE_TEMPLATE/feature_request.yml) provided.
+Please provide as much detail as possible, including the problem you are trying to solve and the solution you would like to see,
+along with possible alternatives you have considered if applicable. Understanding the use cases and the benefits the new feature
+or enhancement would bring to users helps the team to prioritize and implement the feature.
+
+### Doc Changes
+
+Documentation changes are always welcome. If you see a typo, or would like to improve the documentation in any way feel
+free to open a PR. If you are unsure about the changes you would like to make or if the changes go well beyond 
+addressing simple grammar mistakes or formatting, open an issue to discuss the changes before opening a PR.
+
+### Opening PRs
+
+When opening new PRs it is advised to open an issue first to discuss the changes you would like to make. 
+This helps to ensure that the changes are in line with the project goals and that the team is aware of the changes being made
+so that duplicate efforts are not made and everyone's time is used efficiently.
+
+When opening a PR, please ensure that the PR description includes the issue number that the PR is addressing. 
+This helps to ensure that the PR is linked to the issue and that the issue is closed when the PR is merged.
+
+
+### Contributor License Agreement
+
+Before opening a PR, please review LICENSE.md and familiarize yourself with its terms.
+Please be advised that by opening a PR, you are granting Strangelove (or the owner of the relevant repository) a perpetual,
+worldwide, non-exclusive, no-charge, royalty-free, irrevocable license, in copyright and in patent, with respect to your
+Contribution and any portion thereof.

SECURITY.md

@@ -7,3 +7,6 @@ To report a security issue, please use the GitHub Security Advisory ["Report a V
 The Strangelove team will send a response indicating the next steps in handling your report. After the initial reply to your report, the security team will keep you informed of the progress towards a fix and full announcement, and may ask for additional information or guidance. We may also coordinate with Amulet or other security consultants in the Cosmos/IBC space. 
 
 Report security bugs in third-party modules or plugins to the person or team maintaining the module. 
+
+The GitHub Security Advisory "Report a Vulnerability" tab should always be the first step in reporting a security related issue. 
+If for some reason you are unable to report through GitHub, please contact the Strangelove team at [email protected].