chore: adds directory structure and contribution guidelines

.github/CONTRIBUTING.md

@@ -0,0 +1,130 @@
+# Contributing
+We like contributions, Thanks for taking time to contribute and helping us make this project better! The following is a set of guidelines for contributing to awesome-cloudops-automation. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.
+
+When contributing to this repository, please first discuss the change you wish to make via GitHub issue.
+
+Please note we have a code of conduct, please follow it in all your interactions with the project.
+
+## Submitting bugs
+
+### Due diligence
+-------------
+
+Before submitting a bug, please do the following:
+
+* Perform **basic troubleshooting** steps:
+
+* **Search the GitHub issues** to make sure it's not a known
+ issue.
+* If you don't find a pre-existing issue, consider **checking with the slack channel** in case the problem is non-bug-related.
+
+### What to put in your issue
+------------------------------
+
+Make sure issue you raised gets the attention it deserves: issues with missing
+information may be ignored or punted back to you, delaying a fix.  The below
+constitutes a bare minimum; more info is almost always better:
+
+* **What version of the core programming language interpreter/compiler are you
+ using?** For example, Most of our services are written in Java so you what version of Java you're on?
+* **What operating system are you on?** Windows? (10? Home? Pro?)
+ Mac OS X?  (10.x.x?) Linux? (Which distro? Which version of that
+ distro? 32 or 64 bits?) Again, more detail is better.
+* **Are you using latest codebase and are on main branch?** Ideally, you
+ followed the advice above and have ruled out (or verified that the problem
+ exists in) a few different versions.
+* **How can the developers recreate the bug on their end?** If possible,
+ include a copy of your code or an example repo, the command you used to invoke it, and the full
+ output of your run (if applicable.)
+
+### Version control branching
+-------------------------
+
+* Always **make a new branch** for your work, no matter how small. This makes
+ it easy for others to take just that one set of changes from your repository,
+ in case you have multiple unrelated changes floating around.
+
+   * A corollary: **don't submit unrelated changes in the same branch/pull
+     request**! The maintainer shouldn't have to reject your awesome bugfix
+     because the feature you put in with it needs more review.
+
+* **Base your new branch off of the appropriate branch** on the main
+ repository:
+
+   * **Bug fixes** should be based on the branch named after the **oldest
+     supported release line** the bug affects.
+
+       * E.g. if a feature was introduced in 1.1, the latest release line is
+         1.3, and a bug is found in that feature - make your branch based on
+         1.1.  The maintainer will then forward-port it to 1.3 and master.
+       * Bug fixes requiring large changes to the code or which have a chance
+         of being otherwise disruptive, may need to base off of **main**
+         instead. This is a judgement call -- ask the devs!
+
+   * **New features** should branch off of **the 'main' branch**.
+
+       * Note that depending on how long it takes for the dev team to merge
+         your patch, the copy of ``main`` you worked off of may get out of
+         date! If you find yourself 'bumping' a pull request that's been
+         sidelined for a while, **make sure you rebase or merge to latest
+         main** to ensure a speedier resolution.
+
+### Tests aren't optional
+---------------------
+
+Any bugfix that doesn't include a test proving the existence of the bug being
+fixed, may be suspect.  Ditto for new features that can't prove they actually
+work.
+
+We've found that test-first development really helps make features better
+architected and identifies potential edge cases earlier instead of later.
+Writing tests before the implementation is strongly encouraged.
+
+## Full example
+------------
+
+Here's an example workflow for a project `theproject` hosted on Github, which
+is currently in version 1.0.x. Your username is `yourname` and you're
+submitting a basic bugfix. (This workflow only changes slightly if the project
+is hosted at Bitbucket, self-hosted, or etc.)
+
+### Preparing your Fork
+
+
+1. Click 'Fork' on Github, creating e.g. `yourname/theproject`.
+2. Clone your project: `git clone [email protected]:yourname/theproject`.
+3. `cd theproject`
+4. Create a branch: `git checkout -b foo-the-bars 1.0`.
+
+### Making your Changes
+
+
+1. Write tests expecting the correct/fixed functionality; make sure they fail.
+2. Hack, hack, hack.
+3. Run tests again, making sure they pass.
+4. Commit your changes: `git commit -m "Foo the bars"`
+
+### Creating Pull Requests
+
+
+1. Push your commit to get it back up to your fork: `git push origin HEAD`
+2. Visit Github, click handy "Pull request" button that it will make upon
+  noticing your new branch.
+3. In the description field, write down issue number (if submitting code fixing
+  an existing issue) or describe the issue + your fix (if submitting a wholly
+  new bugfix).
+4. Hit 'submit'! And please be patient - the maintainers will get to you when
+  they can.
+
+## Support Channels
+---
+Whether you are a user or contributor, official support channels include:
+- GitHub issues: hhttps://github.com/unskript/Awesome-CloudOps-Automation/issues/new
+- Slack: 
+
+## Sources
+---
+
+Currently this document draws from the contribution documentation for a handful
+of some open source projects: [Fabric](http://fabfile.org), [Invoke](http://pyinvoke.org), [Paramiko](http://paramiko.org), etc.
+

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,25 @@
+## Description
+Please include a summary of the change, motivation and context.
+
+<!--
+- **on a feature**: describe the feature and how this change fits in it, e.g. this PR makes kafka message.max.bytes configurable to better support batching
+- **on a refactor**: describe why this is better than previous situation e.g. this PR changes logic for retry on healthchecks to avoid false positives
+- **on a bugfix**: link relevant information about the bug (github issue or slack thread) and how this change solves it e.g. this change fixes #99999 by adding a lock on read/write to avoid data races.
+-->
+
+
+### Testing
+Please describe the tests that you ran to verify your changes. Please summarize what did you test and what needs to be tested e.g. deployed and tested helm chart locally. 
+
+### Checklist:
+- [ ] My changes generate no new warnings.
+- [ ] I have added tests that prove my fix is effective or that my feature works.
+- [ ] Any dependent changes have been merged and published. 
+
+### Documentation
+Make sure that you have documented corresponding changes in this repository. 
+
+<!--
+Include __important__ links regarding the implementation of this PR.
+This usually includes and RFC or an aggregation of issues and/or individual conversations that helped put this solution together. This helps ensure there is a good aggregation of resources regarding the implementation.
+-->

.github/code-of-conduct.md

@@ -0,0 +1,128 @@
+# Unskript Code of Conduct
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our
+community a harassment-free experience for everyone, regardless of age, body
+size, visible or invisible disability, ethnicity, sex characteristics, gender
+identity and expression, level of experience, education, socio-economic status,
+nationality, personal appearance, race, religion, or sexual identity
+and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming,
+diverse, inclusive, and healthy community.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our
+community include:
+
+* Demonstrating empathy and kindness toward other people
+* Being respectful of differing opinions, viewpoints, and experiences
+* Giving and gracefully accepting constructive feedback
+* Accepting responsibility and apologizing to those affected by our mistakes,
+  and learning from the experience
+* Focusing on what is best not just for us as individuals, but for the
+  overall community
+
+Examples of unacceptable behavior include:
+
+* The use of sexualized language or imagery, and sexual attention or
+  advances of any kind
+* Trolling, insulting or derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or email
+  address, without their explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Enforcement Responsibilities
+
+Community leaders are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any behavior that they deem inappropriate, threatening, offensive,
+or harmful.
+
+Community leaders have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, and will communicate reasons for moderation
+decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public spaces.
+Examples of representing our community include using an official e-mail address,
+posting via an official social media account, or acting as an appointed
+representative at an online or offline event.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported to the community leaders responsible for enforcement at [[email protected]](mailto:[email protected]).
+All complaints will be reviewed and investigated promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of the
+reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining
+the consequences for any action they deem in violation of this Code of Conduct:
+
+### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior deemed
+unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders, providing
+clarity around the nature of the violation and an explanation of why the
+behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community Impact**: A violation through a single incident or series
+of actions.
+
+**Consequence**: A warning with consequences for continued behavior. No
+interaction with the people involved, including unsolicited interaction with
+those enforcing the Code of Conduct, for a specified period of time. This
+includes avoiding interactions in community spaces as well as external channels
+like social media. Violating these terms may lead to a temporary or
+permanent ban.
+
+### 3. Temporary Ban
+
+**Community Impact**: A serious violation of community standards, including
+sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public
+communication with the community for a specified period of time. No public or
+private interaction with the people involved, including unsolicited interaction
+with those enforcing the Code of Conduct, is allowed during this period.
+Violating these terms may lead to a permanent ban.
+
+### 4. Permanent Ban
+
+**Community Impact**: Demonstrating a pattern of violation of community
+standards, including sustained inappropriate behavior,  harassment of an
+individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within
+the community.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 2.0, available at
+https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
+
+Community Impact Guidelines were inspired by [Mozilla's code of conduct
+enforcement ladder](https://github.com/mozilla/diversity).
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see the FAQ at
+https://www.contributor-covenant.org/faq. Translations are available at
+https://www.contributor-covenant.org/translations.
+