Add CNCF project governance

Adding the required governance for the project to become part of the
CNCF.

Signed-off-by: Sascha Grunert <[email protected]>

CODE_OF_CONDUCT.md

@@ -0,0 +1,7 @@
+# Code of Conduct
+
+We follow the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md).
+
+Please contact one of the [project maintainers](MAINTAINERS.md) or the [CNCF
+Code of Conduct Committee](mailto:[email protected]) in order to report violations
+of the Code of Conduct.

GOVERNANCE.md

@@ -0,0 +1,151 @@
+# oci-spec-rs Project Governance
+
+The oci-spec-rs project is dedicated to creating an OCI Runtime, Image and
+Distribution specification in Rust. This governance explains how the project is
+run.
+
+- [Values](#values)
+- [Maintainers](#maintainers)
+- [Becoming a Maintainer](#becoming-a-maintainer)
+- [Meetings](#meetings)
+- [CNCF Resources](#cncf-resources)
+- [Code of Conduct Enforcement](#code-of-conduct)
+- [Security Response Team](#security-response-team)
+- [Voting](#voting)
+- [Modifications](#modifying-this-charter)
+
+## Values
+
+The oci-spec-rs project and its leadership embrace the following values:
+
+- Openness: Communication and decision-making happens in the open and is
+  discoverable for future reference. As much as possible, all discussions and
+  work take place in public forums and open repositories.
+
+- Fairness: All stakeholders have the opportunity to provide feedback and submit
+  contributions, which will be considered on their merits.
+
+- Community over Product or Company: Sustaining and growing our community takes
+  priority over shipping code or sponsors' organizational goals. Each
+  contributor participates in the project as an individual.
+
+- Inclusivity: We innovate through different perspectives and skill sets, which
+  can only be accomplished in a welcoming and respectful environment.
+
+- Participation: Responsibilities within the project are earned through
+  participation, and there is a clear path up the contributor ladder into
+  leadership positions.
+
+## Maintainers
+
+oci-spec-rs Maintainers have write access to the project GitHub repository.
+They can merge their own patches or patches from others. The current maintainers
+can be found in [MAINTAINERS.md](MAINTAINERS.md). Maintainers collectively
+manage the project's resources and contributors.
+
+This privilege is granted with some expectation of responsibility: maintainers
+are people who care about the oci-spec-rs project and want to help it grow and
+improve. A maintainer is not just someone who can make changes, but someone who
+has demonstrated their ability to collaborate with the team, get the most
+knowledgeable people to review code and docs, contribute high-quality code, and
+follow through to fix issues (in code or tests).
+
+A maintainer is a contributor to the project's success and a citizen helping the
+project succeed.
+
+The collective team of all Maintainers is known as the Maintainer Council, which
+is the governing body for the project.
+
+### Becoming a Maintainer
+
+To become a Maintainer you need to demonstrate the following:
+
+- commitment to the project:
+  - participate in discussions, contributions, code and documentation reviews
+    for 3 months or more,
+  - perform reviews for at least 10 non-trivial pull requests,
+  - contribute at least 5 non-trivial pull requests and have them merged,
+- ability to write quality code and/or documentation,
+- ability to collaborate with the team,
+- understanding of how the team works (policies, processes for testing and code
+  review, etc),
+- understanding of the project's code base and coding and documentation style.
+
+A new Maintainer must be proposed by an existing maintainer by opening an issue
+within this repository. A simple majority vote of existing Maintainers approves
+the application. Maintainers nominations will be evaluated without prejudice to
+employer or demographics.
+
+Maintainers who are selected will be granted the necessary GitHub rights.
+
+### Removing a Maintainer
+
+Maintainers may resign at any time if they feel that they will not be able to
+continue fulfilling their project duties.
+
+Maintainers may also be removed after being inactive, failure to fulfill their
+Maintainer responsibilities, violating the Code of Conduct, or other reasons.
+Inactivity is defined as a period of very low or no activity in the project
+for a year or more, with no definite schedule to return to full Maintainer
+activity.
+
+A Maintainer may be removed at any time by a 2/3 vote of the remaining
+maintainers.
+
+Depending on the reason for removal, a Maintainer may be converted to Emeritus
+status. Emeritus Maintainers will still be consulted on some project matters,
+and can be rapidly returned to Maintainer status if their availability changes.
+
+## Meetings
+
+There are no public meetings planned for this particular project.
+
+Maintainers may have closed meetings in order to discuss security reports or
+Code of Conduct violations. Such meetings should be scheduled by any Maintainer
+on receipt of a security issue or CoC report. All current Maintainers must be
+invited to such closed meetings, except for any Maintainer who is accused of a
+CoC violation.
+
+## CNCF Resources
+
+Any Maintainer may suggest a request for CNCF resources, either as issue or
+discussion within this repository or during a meeting. A simple majority of
+Maintainers approves the request. The Maintainers may also choose to delegate
+working with the CNCF to non-Maintainer community members, who will then be
+added to the [CNCF's Maintainer
+List](https://github.com/cncf/foundation/blob/main/project-maintainers.csv)
+for that purpose.
+
+## Code of Conduct
+
+[Code of Conduct](CODE_OF_CONDUCT.md) violations by community members will be
+discussed and resolved by the Maintainers privately. If a Maintainer is directly
+involved in the report, the Maintainers will instead designate two Maintainers
+to work with the CNCF Code of Conduct Committee in resolving it.
+
+## Security Response Team
+
+The Maintainers will appoint a Security Response Team to handle security
+reports. This committee may simply consist of the Maintainer Council themselves.
+If this responsibility is delegated, the Maintainers will appoint a team of at
+least two contributors to handle it. The Maintainers will review who is assigned
+to this at least once a year.
+
+The Security Response Team is responsible for handling all reports of security
+holes and breaches according to the [security policy](SECURITY.md).
+
+## Voting
+
+While most business in oci-spec-rs is conducted by "[lazy
+consensus](https://community.apache.org/committers/lazyConsensus.html)",
+periodically the Maintainers may need to vote on specific actions or changes. A
+vote can be taken on an GitHub issue or discussion within the project.
+
+Most votes require a simple majority of all Maintainers to succeed, except where
+otherwise noted. Two-thirds majority votes mean at least two-thirds of all
+existing maintainers.
+
+## Modifying this Charter
+
+Changes to this Governance and its supporting documents may be approved by a 2/3
+vote of the Maintainers.

MAINTAINERS.md

@@ -0,0 +1,17 @@
+The current Maintainers Group for the oci-spec-rs project consists of:
+
+| Name            | Employer           | GitHub handle    | Responsibilities        |
+| --------------- | ------------------ | ---------------- | ----------------------- |
+| Colin Walters   | Red Hat            | @cgwalters       | Approver and Maintainer |
+| Flavio Castelli | SUSE               | @flavio          | Approver and Maintainer |
+| Sascha Grunert  | Red Hat            | @saschagrunert   | Approver and Maintainer |
+| Taylor Thomas   | Cosmonic           | @thomastaylor312 | Approver and Maintainer |
+| Toru Komatsu    | Preferred Networks | @utam0k          | Approver and Maintainer |
+| Eric Fang       | Independent        | @yihuaf          | Maintainer              |
+| Jorge Prendes   | Independent        | @jprendes        | Maintainer              |
+| Thomas Schubart | Gitpod             | @Furisto         | Maintainer              |
+| Yashodhan       | Independent        | @YJDoc2          | Maintainer              |
+
+This list must be kept in sync with the [CNCF Project Maintainers list](https://github.com/cncf/foundation/blob/master/project-maintainers.csv).
+
+See [the project Governance](GOVERNANCE.md) for how maintainers are selected and replaced.

SECURITY.md

@@ -0,0 +1,37 @@
+# oci-spec-rs Security
+
+Security is taken seriously and has high priority across all related projects to
+ensure users can trust this project for their systems.
+
+We're extremely grateful for security researchers and users that report
+vulnerabilities to the community. All reports are thoroughly investigated by a
+set of community volunteers.
+
+## Report a Vulnerability
+
+<!-- TODO: the mailing list has to be requested -->
+
+To make a report, email the vulnerability to the private
+[[email protected]](mailto:[email protected]) list
+with the security details.
+
+You can expect an initial response to the report within 3 business days.
+Possible fixes for vulnerabilities will be then discussed via the mail thread
+and can be considered as automatically embargoed until they got merged into all
+related branches. A project approver or reviewer (as defined in the
+[OWNERS](./OWNERS) file) will coordinate how the pull requests and patches are
+being incorporated into the repository without breaking the embargo.
+
+### When Should I Report a Vulnerability?
+
+- You think you discovered a potential security vulnerability
+- You are unsure how a vulnerability affects this project
+- You think you discovered a vulnerability in another project that oci-spec-rs
+  depends on (for projects with their own vulnerability reporting and disclosure
+  process, please report it directly there)
+
+### When Should I NOT Report a Vulnerability?
+
+- You need help tuning components for security
+- You need help applying security related updates
+- Your issue is not security related

SECURITY_CONTACTS

@@ -0,0 +1,17 @@
+# Defined below are the security contacts for this repo.
+#
+# They are the contact point for the Product Security Team to reach out
+# to for triaging and handling of incoming issues.
+#
+# The below names agree to abide by the
+# [Embargo Policy](https://git.k8s.io/security/private-distributors-list.md#embargo-policy)
+# and will be removed and replaced if they violate that agreement.
+#
+# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE
+# INSTRUCTIONS AT ./SECURITY.md
+
+cgwalters
+flavio
+saschagrunert
+thomastaylor312
+utam0k