Add governance artefacts to tremor-benchmark repo

Signed-off-by: Darach Ennis <[email protected]>

CODEOWNERS

@@ -0,0 +1,4 @@
+# Tremor code owners core team
+*       @anupdhml @darach @Licenser @mfelsche
+# Tremor benchmark continuous integration contributors
+*       @humancalico

CODE_OF_CONDUCT.md

@@ -0,0 +1,44 @@
+# The Tremor Code of Conduct
+
+A version of this document [can be found online](https://docs.tremor.rs/CodeOfConduct).
+
+## Conduct
+
+**Contact**: [[email protected]](mailto:[email protected]?subject=Tremor+Moderator+Team)
+
+* We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic.
+* On tremor-chat, please avoid using overtly sexual nicknames or other nicknames that might detract from a friendly, safe and welcoming environment for all.
+* Please be kind and courteous. There's no need to be mean or rude.
+* Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer.
+* Please keep unstructured critique to a minimum. If you have solid ideas you want to experiment with, make a fork and see how it works.
+* We will exclude you from interaction if you insult, demean or harass anyone. That is not welcome behavior. We interpret the term "harassment" as including the definition in the [Citizen Code of Conduct](http://citizencodeofconduct.org/); if you have any lack of clarity about what might be included in that concept, please read their definition. In particular, we don't tolerate behavior that excludes people in socially marginalized groups.
+* Private harassment is also unacceptable. No matter who you are, if you feel you have been or are being harassed or made uncomfortable by a community member, please contact one of the channel ops or any of the [Tremor moderation team][mod_team] immediately. Whether you're a regular contributor or a newcomer, we care about making this community a safe place for you and we've got your back.
+* Likewise any spamming, trolling, flaming, baiting or other attention-stealing behavior is not welcome.
+
+## Moderation
+
+
+These are the policies for upholding our community's standards of conduct. If you feel that a thread needs moderation, please contact the [Tremor moderation team][mod_team].
+
+1. Remarks that violate the Tremor standards of conduct, including hateful, hurtful, oppressive, or exclusionary remarks, are not allowed. (Cursing is allowed, but never targeting another user, and never in a hateful manner.)
+2. Remarks that moderators find inappropriate, whether listed in the code of conduct or not, are also not allowed.
+3. Moderators will first respond to such remarks with a warning.
+4. If the warning is unheeded, the user will be "kicked," i.e., kicked out of the communication channel to cool off.
+5. If the user comes back and continues to make trouble, they will be banned, i.e., indefinitely excluded.
+6. Moderators may choose at their discretion to un-ban the user if it was a first offense and they offer the offended party a genuine apology.
+7. If a moderator bans someone and you think it was unjustified, please take it up with that moderator, or with a different moderator, **in private**. Complaints about bans in-channel are not allowed.
+8. Moderators are held to a higher standard than other community members. If a moderator creates an inappropriate situation, they should expect less leeway than others.
+
+In the Tremor community we strive to go the extra step to look out for each other. Don't just aim to be technically unimpeachable, try to be your best self. In particular, avoid flirting with offensive or sensitive issues, particularly if they're off-topic; this all too often leads to unnecessary fights, hurt feelings, and damaged trust; worse, it can drive people away from the community entirely.
+
+And if someone takes issue with something you said or did, resist the urge to be defensive. Just stop doing what it was they complained about and apologize. Even if you feel you were misinterpreted or unfairly accused, chances are good there was something you could've communicated better — remember that it's your responsibility to make your fellow tremolos comfortable. Everyone wants to get along and we are all here first and foremost because we want to talk about cool technology. You will find that people will be eager to assume good intent and forgive as long as you earn their trust.
+
+The enforcement policies listed above apply to all official Tremor venues; including official tremor-chat channels (#tremor, #tremor-internals, #tremor-tools, #tremor-libs, #tremor-beginners, #tremor-docs, #tremor-community, #tremor-lang); GitHub repositories under tremor-rs; and all forums under tremo.rs. For other projects adopting the Tremor Code of Conduct, please contact the maintainers of those projects for enforcement. If you wish to use this code of conduct for your own project, consider explicitly mentioning your moderation policy or making a copy with your own moderation policy so as to avoid confusion.
+
+*Adapted from the [Node.js Policy on Trolling](http://blog.izs.me/post/30036893703/policy-on-trolling) as well as the [Contributor Covenant v1.3.0](https://www.contributor-covenant.org/version/1/3/0/).*
+
+[mod_team]: https://www.tremor.rs/community/teams/#moderation-mod
+
+## Origins
+
+This code of conduct is derived from the Rust Language Community code of conduct that [can be found here](https://www.rust-lang.org/conduct.html)

CONTRIBUTING.md

@@ -0,0 +1,215 @@
+# Contributing to Tremor
+
+[contributing-to-tremor]: #contributing-to-tremor
+
+Thank you for your interest in contributing to the Tremor project! There are many ways to
+contribute, and we appreciate all of them. Here's links to the primary ways to contribute
+to the Tremor project as an external contributor:
+
+- [Contributing to Tremor](#contributing-to-tremor)
+  - [Feature Requests](#feature-requests)
+  - [Bug Reports](#bug-reports)
+  - [The Build System](#the-build-system)
+  - [Pull Requests](#pull-requests)
+    - [External Dependencies](#external-dependencies)
+  - [Writing Documentation](#writing-documentation)
+  - [Issue Triage](#issue-triage)
+  - [Out-of-tree Contributions](#out-of-tree-contributions)
+  - [Tremor Chat](#tremor-chat)
+
+If you have questions, please make a query hop on over to [Tremor Chat][tremor-chat].
+
+As a reminder, all contributors are expected to follow our [Code of Conduct][code-of-conduct].
+
+If this is your first time contributing, we would like to thank you for spending time
+on the project! Please reach out directly to any core project member if you would like
+any guidance or assistance.
+
+[code-of-conduct]: https://docs.tremor.rs/CodeOfConduct
+
+## Feature Requests
+
+[feature-requests]: #feature-requests
+
+To request a change to the way that Tremor works, please head over
+to the [RFCs repository](https://github.com/tremor-rs/tremor-rfcs) and view the
+[README](https://github.com/tremor-rs/tremor-rfcs/blob/main/README.md)
+for instructions.
+
+## Bug Reports
+
+[bug-reports]: #bug-reports
+
+While bugs are unfortunate, they're a reality in software. We can't fix what we
+don't know about, so please report liberally. If you're not sure if something
+is a bug or not, feel free to file a bug anyway.
+
+**If you believe reporting your bug publicly represents a security risk to Tremor users,
+please follow our [instructions for reporting security vulnerabilities](https://docs.tremor.rs/policies/security)**.
+
+If you have the chance, before reporting a bug, please [search existing
+issues](https://github.com/tremor-rs/tremor-runtime/search?q=&type=Issues&utf8=%E2%9C%93),
+as it's possible that someone else has already reported your error. This doesn't
+always work, and sometimes it's hard to know what to search for, so consider this
+extra credit. We won't mind if you accidentally file a duplicate report.
+
+Similarly, to help others who encountered the bug find your issue,
+consider filing an issue with a descriptive title, which contains information that might be unique to it.
+This can be the language or compiler feature used, the conditions that trigger the bug,
+or part of the error message if there is any.
+An example could be: **"impossible case reached" on match expression in tremor scripting language**.
+
+Opening an issue is as easy as following [this
+link](https://github.com/tremor-rs/tremor-runtime/issues/new) and filling out the fields.
+Here's a template that you can use to file a bug, though it's not necessary to
+use it exactly:
+
+```
+    <short summary of the bug>
+
+    I tried this code:
+
+    <code sample that causes the bug>
+
+    I expected to see this happen: <explanation>
+
+    Instead, this happened: <explanation>
+
+    ## Meta
+
+    `tremor-script --version`:
+
+    Backtrace:
+```
+
+All three components are important: what you did, what you expected, what
+happened instead. Please include the output of `tremor --version`,
+which includes important information about what platform you're on, what
+version of Rust you're using, etc.
+
+Sometimes, a backtrace is helpful, and so including that is nice. To get
+a backtrace, set the `RUST_BACKTRACE` environment variable to a value
+other than `0`. The easiest way to do this is to invoke `tremor` like this:
+
+```bash
+$ RUST_BACKTRACE=1 tremor...
+```
+
+## The Build System
+
+For info on how to configure and build the project, please see [the tremor build guide][tremor-build-guide].
+This guide contains info for contributions to the project and the standard facilities. It also lists some
+really useful commands to the build system, which could save you a lot of time.
+
+[tremor-build-guide]: http://docs.tremor.rs/development/quick-start/
+
+## Pull Requests
+
+[pull-requests]: #pull-requests
+
+Pull requests are the primary mechanism we use to change Tremor. GitHub itself
+has some [great documentation][about-pull-requests] on using the Pull Request feature.
+We use the "fork and pull" model [described here][development-models], where
+contributors push changes to their personal fork and create pull requests to
+bring those changes into the source repository.
+
+[about-pull-requests]: https://help.github.com/articles/about-pull-requests/
+[development-models]: https://help.github.com/articles/about-collaborative-development-models/
+
+Please make pull requests against the `main` branch.
+
+Tremor follows a no merge policy, meaning, when you encounter merge
+conflicts you are expected to always rebase instead of merge.
+E.g. always use rebase when bringing the latest changes from
+the main branch to your feature branch.
+Also, please make sure that fixup commits are squashed into other related
+commits with meaningful commit messages.
+
+GitHub allows [closing issues using keywords][closing-keywords]. This feature
+should be used to keep the issue tracker tidy. However, it is generally preferred
+to put the "closes #123" text in the PR description rather than the issue commit;
+particularly during rebasing, citing the issue number in the commit can "spam"
+the issue in question.
+
+[closing-keywords]: https://help.github.com/en/articles/closing-issues-using-keywords
+
+Please make sure your pull request is in compliance with Tremor's style
+guidelines by running
+
+    $ sh ./contrib/pre-commit
+
+Make this check before every pull request (and every new commit in a pull
+request); you can add [git hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)
+before every push to make sure you never forget to make this check.
+
+All pull requests are reviewed by another person.
+
+If you want to request that a specific person reviews your pull request,
+you can add an `r?` to the pull request description. For example, [Darach Ennis][darach] usually reviews
+documentation changes. So if you were to make a documentation change, add
+
+    r? @darach
+
+to the end of the pull request description. This is entirely optional.
+
+After someone has reviewed your pull request, they will leave an annotation
+on the pull request with an `r+`. It will look something like this:
+
+    r+
+
+Once your merge request is approved it will enter the merge queue
+
+[darach]: https://github.com/darach
+
+Speaking of tests, tremor has a comprehensive test suite. More information about
+it can be found [here][https://github.com/tremor-rs/tremor-www-docs/blob/main/docs/development/testing.md].
+
+### External Dependencies
+
+Currently building the Tremor project will also build the following external projects:
+
+- [clippy](https://github.com/rust-lang/rust-clippy)
+- [rustfmt](https://github.com/rust-lang/rustfmt)
+
+Breakage is not allowed in released branches and must be addressed before a PR is merged.
+
+## Writing Documentation
+
+Documentation improvements are very welcome. The source of `docs.tremor.rs`
+is located in the [tremor docs repo](https://github.com/tremor-rs/tremor-www-docs). Documentation pull requests function in the same way as other pull requests.
+
+To find documentation-related issues, sort by the [doc label][tremor-doc-label].
+
+[tremor-doc-label]: https://github.com/tremor-rs/tremor-www-docs/issues?q=is%3Aopen%20is%3Aissue%20label%3Adoc
+
+Additionally, contributions to the [tremor-guide] are always welcome. Contributions
+can be made directly [here](https://github.com/tremor-rs/tremor-www-docs) repo. The issue
+tracker in that repo is also a great way to find things that need doing.
+
+## Issue Triage
+
+Sometimes, an issue will stay open, even though the bug has been fixed. And
+sometimes, the original bug may go stale because something has changed in the
+meantime.
+
+It can be helpful to go through older bug reports and make sure that they are
+still valid. Load up an older issue, double check that it's still true, and
+leave a comment letting us know if it is or is not. The [least recently
+updated sort][lru] is good for finding issues like this.
+
+[lru]: https://github.com/tremor-rs/tremor-runtime/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc
+
+## Out-of-tree Contributions
+
+There are a number of other ways to contribute to Tremor that don't deal with
+this repository.
+
+Answer questions in the _Get Help!_ channels from the [Tremor Chat][tremor-chat].
+
+Participate in the [RFC process](https://github.com/tremor-rs/tremor-rfcs).
+
+## Tremor Chat
+
+[tremor-chat]: #tremor-chat
+
+Join the tremor community [discord](https://bit.ly/tremor-discord)

README.md

@@ -0,0 +1,8 @@
+** tremor-benchmark **
+
+This repository contains code for our continuous integration system that enables our project
+benchmarks to be executed on a CNCF Cluster bare metal Equinix machine via github actions.
+
+This tool was conceived and developed by [Akshat Agarwal]([humancalico]) for the LFX Spring 2021 mentorship program.
+
+[humancalico]: https://github.com/humancalico

SECURITY.md

@@ -0,0 +1,75 @@
+# Security
+
+The tremor project follows strict coding practices that help to reduce the incidence,
+surface and likelihood of direct or indirect security risks to users of the software.
+
+Specifically:
+
+  * Tremor favors safe over unsafe rust code.
+    * Safe code is generally considered the better option
+    * Unless, performance critical concerns on the hot path suggest otherwise
+    * Over time, unsafe code should be displaced with safe code
+  * Tremor is conservative on matters of code health.
+    * Clippy is pedantic mode is mandated for all rust code
+    * Property based testing, model-based testing and fuzz-testing are used
+    * Additional audits for code quality are in force
+  * Static analysis
+    * Tremor analyses external library dependencies for all direct and indirect dependencies
+    * Tremor logs and reports all LICENSE, CVE and other violations both in our CI code and using other tools
+    * Additional dynamic and static analysis methods can be added to broaden/deepen coverage
+
+
+# Non Recommendation
+
+We do *not* recommend running tremor outside of corporate firewalls at this time.
+
+Although every care is taken to ensure there are no security flaws within the code-base
+tremor, to date, has been designed with deployment in secure, well-defended environments
+with active intrusion detection and defenses run by security professionals.
+
+
+# Recommendation
+
+We do recommend running tremor in secured environments following the best practices of
+the organization and deployment platform. For example, the security blueprints for deploying
+secure services to Amazon's infrastructure should be followed when deploying to AWS. The
+security blueprints for the Google Cloud Platform should be followed when deploying to GCP.
+
+Where tremor is deployed into bespoke bare metal data centers, tremor should be treated as
+software that is not secure in and of itself. A secured environment should be provided for
+it to run within.
+
+# Future
+
+Contributions to tremor security are very welcome, highly encouraged and we would be
+delighted to accept contributions that move our security roadmap priority.
+
+# Disclosing Security Issues
+
+Safety is a core principle of Tremor, and one of the prime reasons why we adopted the
+Rust Programming language to write Tremor. To that end, we would like to ensure that
+Tremor has a secure implementation with no inherent security issues.
+
+Thank you for taking the time to responsibly disclose any issues you find.
+
+All security bugs in the tremor project should be reported by email to <a href="mailto:[email protected]">[email protected]</a>. This list is delivered to a small team. Your email will be acknowledged within 24 hours, and you’ll receive a more detailed response to your email within 48 hours indicating the next steps in handling your report. 
+
+If you would like, you can encrypt your report using a public key. This key can be requested from the security
+team via direct email, or through contacting us on our slack community and requesting same.
+
+Be sure to use a descriptive subject line in email to avoid having your report missed. After the initial reply
+to your report, the security team will endeavor to keep you informed of the progress being made towards a fix
+and full announcement.
+
+## Public keys for disclosures
+
+
+If you have not received a reply to your email within 48 hours, or have not heard from the security team for the past five days, there are a few steps you can take (in order):
+
+Contact the current security coordinator (Darach Ennis) directly [pgp key](https://pgp.mit.edu/pks/lookup?op=get&search=0x962FAC01B6989EBB).
+Contact the back-up contact (Heinz Gies) directly [pgp key](https://keys.openpgp.org/vks/v1/by-fingerprint/71C9D7794FCEAC9D77AC4F6FE21BB9BD3F38481E).
+
+Post a friendly reminder on the community slack.
+
+Please note that discussion forums are public areas. When escalating in these venues, please do not
+discuss your issue. Simply say that you’re trying to get a hold of someone from the security team.