Maintainers + Governance + Security docs (#671)

* governance and mainteners in the style of linkerd

Signed-off-by: clux <[email protected]>

* simplify governance and remove meeting requirement

we don't do regular meetings - everything is ad-hoc async.

Signed-off-by: clux <[email protected]>

* add a basic security policy

Signed-off-by: clux <[email protected]>

* remove quote from linkerd article

Signed-off-by: clux <[email protected]>

* potential wording of release tasks

Signed-off-by: clux <[email protected]>

* dot

Signed-off-by: clux <[email protected]>

* Update maintainers.md

Co-authored-by: kazk <[email protected]>

* Update CONTRIBUTING.md

Co-authored-by: Teo Klestrup Röijezon <[email protected]>

Co-authored-by: kazk <[email protected]>
Co-authored-by: Teo Klestrup Röijezon <[email protected]>

Author: 3 people

CONTRIBUTING.md

@@ -16,9 +16,9 @@ process. To contribute a PR, fork this project, create a new branch, make
 changes on that branch, and then use GitHub to open a pull request with your
 changes.
 
-Every PR must be reviewed by at least one [Core Maintainer](https://github.com/orgs/kube-rs/teams/core-maintainers) of the project. Once
-a PR has been marked "Approved" by a Core Maintainer (and no other core
-maintainer has an open "Rejected" vote), the PR may be merged. While it is fine
+Every PR must be reviewed by at least one [Maintainer](./maintainers.md) of the project. Once
+a PR has been marked "Approved" by a Maintainer (and no other
+Maintainer has an open "Rejected" vote), the PR may be merged. While it is fine
 for non-maintainers to contribute their own code reviews, those reviews do not
 satisfy the above requirement.
 

SECURITY.md

@@ -0,0 +1,25 @@
+# Security Policy
+
+## Supported Versions
+
+We provide security updates for the two most recent minor versions released on `crates.io`.
+
+For example, if `0.70.1` is the most recent stable version, we will address security updates for `0.69` and later.
+Once `0.71.1` is released, we will no longer provide updates for `0.69` releases.
+
+## Reporting a Vulnerability
+
+To report a security problem in Kube-rs, please contact at least two [maintainers][./maintainers.md]
+
+These people will help diagnose the severity of the issue and determine how to address the issue.
+Issues deemed to be non-critical will be filed as GitHub issues.
+Critical issues will receive immediate attention and be fixed as quickly as possible.
+
+## Security Advisories
+
+When serious security problems in Kube-rs are discovered and corrected, we issue a security advisory, describing the problem and containing a pointer to the fix.
+
+These are announced the [RustSec Advisory Database](https://github.com/rustsec/advisory-db), to our github issues under the label `critical`, as well as discord and other primary communication channels.
+
+Security issues are fixed as soon as possible, and the fixes are propagated to the stable branches as fast as possible. However, when a vulnerability is found during a code audit, or when several other issues are likely to be spotted and fixed in the near future, the security team may delay the release of a Security Advisory, so that one unique, comprehensive Security Advisory covering several vulnerabilities can be issued.
+Communication with vendors and other distributions shipping the same code may also cause these delays.

governance.md

@@ -0,0 +1,55 @@
+# Kube-rs Governance
+
+This document defines project governance for Kube-rs.
+
+## Contributors
+
+Kube-rs is for everyone. Anyone can become a Kube-rs contributor simply by contributing to the project, whether through code, documentation, blog posts, community management, or other means.
+As with all Kube-rs community members, contributors are expected to follow the [Kube-rs Code of Conduct][coc].
+
+All contributions to Kube-rs code, documentation, or other components in the Kube-rs GitHub org must follow the guidelines in [CONTRIBUTING.md][contrib].
+Whether these contributions are merged into the project is the prerogative of the maintainers.
+
+## Maintainer Expectations
+
+Maintainers have the ability to merge code into the project. Anyone can become a Kube-rs maintainer (see "Becoming a maintainer" below.)
+
+As such, there are certain expectations for maintainers. Kube-rs maintainers are expected to:
+
+* Review pull requests, triage issues, and fix bugs in their areas of expertise, ensuring that all changes go through the project's code review and integration processes.
+* Monitor the Kube-rs Discord, and Discussions and help out when possible.
+* Rapidly respond to any time-sensitive security release processes.
+* Participate on discussions on the roadmap.
+
+If a maintainer is no longer interested in or cannot perform the duties listed above, they should move themselves to emeritus status.
+If necessary, this can also occur through the decision-making process outlined below.
+
+### Maintainer decision-making
+
+Ideally, all project decisions are resolved by maintainer consensus.
+If this is not possible, maintainers may call a vote.
+The voting process is a simple majority in which each maintainer receives one vote.
+
+### Special Tasks
+
+In addition to the outlined abilities and responsibilities outlined above, some maintainer take on additional tasks and responsibilities.
+
+#### Release Tasks
+
+As a maintainer on the release team, you are expected to:
+
+* Cut releases, and update the [CHANGELOG](./CHANGELOG.md)
+* Pre-verify big releases against example repos
+* Publish and update versions in example repos
+* Verify the release
+
+### Becoming a maintainer
+
+Anyone can become a Kube-rs maintainer. Maintainers should be highly proficient in Rust; have relevant domain expertise; have the time and ability to meet the maintainer expectations above; and demonstrate the ability to work with the existing maintainers and project processes.
+
+To become a maintainer, start by expressing interest to existing maintainers.
+Existing maintainers will then ask you to demonstrate the qualifications above by contributing PRs, doing code reviews, and other such tasks under their guidance.
+After several months of working together, maintainers will decide whether to grant maintainer status.
+
+[coc]: https://github.com/kube-rs/kube-rs/blob/master/code-of-conduct.md
+[contrib]: https://github.com/kube-rs/kube-rs/blob/master/CONTRIBUTING.md

maintainers.md

@@ -0,0 +1,23 @@
+# Maintainers
+
+The Kube-rs maintainers are:
+
+* Eirik Albrigtsen <[email protected]> @clux
+* Teo Klestrup Röijezon <[email protected]> @teozkr
+* Kaz Yoshihara <[email protected]> @kazk
+
+## Emeriti
+
+Former maintainers include:
+
+* Ryan Levick <[email protected]> @rylev
+
+<!--
+# Adding a new maintainer
+
+* Submit a PR modifying this file
+* Obtain approvals per governance.md
+* Invite maintainer to
+  https://github.com/orgs/kube-rs/teams/maintainers/members
+* Invite maintainer to https://github.com/orgs/kube-rs/people
+-->