Adding governance.md and updating security.md

.github/SECURITY.md

@@ -44,28 +44,28 @@ The VMware Security Team will respond to vulnerability reports as follows:
 4. If a vulnerability is acknowledged and the timeline for a fix is determined, the Security Team will work on a plan to communicate with the appropriate community, including identifying mitigating steps that affected users can take to protect themselves until the fix is rolled out.
 5. The Security Team will also create a [CVSS](https://www.first.org/cvss/specification-document) using the [CVSS Calculator](https://www.first.org/cvss/calculator/3.0). The Security Team makes the final call on the calculated CVSS; it is better to move quickly than making the CVSS perfect. Issues may also be reported to [Mitre](https://cve.mitre.org/) using this [scoring calculator](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator). The CVE will initially be set to private.
 6. The Security Team will work on fixing the vulnerability and perform internal testing before preparing to roll out the fix.
-7. The Security Team will provide early disclosure of the vulnerability by emailing the [Cartographer Distributors](<DISTRIBUTORS EMAIL LINK>) mailing list. Distributors can initially plan for the vulnerability patch ahead of the fix, and later can test the fix and provide feedback to the Cartographer team. See the section **Early Disclosure to Cartographer Distributors List** for details about how to join this mailing list.
+7. The Security Team will provide early disclosure of the vulnerability by emailing the [Cartographer Distributors](cartographer-distributors@googlegroups.com) mailing list. Distributors can initially plan for the vulnerability patch ahead of the fix, and later can test the fix and provide feedback to the Cartographer team. See the section **Early Disclosure to Cartographer Distributors List** for details about how to join this mailing list.
 8. A public disclosure date is negotiated by the VMware SecurityTeam, the bug submitter, and the distributors list. We prefer to fully disclose the bug as soon as possible once a user mitigation or patch is available. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested, or for distributor coordination. The timeframe for disclosure is from immediate (especially if it’s already publicly known) to a few weeks. For a critical vulnerability with a straightforward mitigation, we expect the report date for the public disclosure date to be on the order of 14 business days. The VMware Security Team holds the final say when setting a public disclosure date.
 9. Once the fix is confirmed, the Security Team will patch the vulnerability in the next patch or minor release, and backport a patch release into all earlier supported releases. Upon release of the patched version of Cartographer, we will follow the **Public Disclosure Process**.
 
 ## Public Disclosure Process
 
-The Security Team publishes a [public advisory](<LINK TO SECURTY ADVISORIES IN YOUR REPO>) to the Cartographer community via GitHub. In most cases, additional communication via Slack, Twitter, mailing lists, blog and other channels will assist in educating Cartographer users and rolling out the patched release to affected users.
+The Security Team publishes a [public advisory](https://github.com/vmware-tanzu/cartographer/security/advisories) to the Cartographer community via GitHub. In most cases, additional communication via Slack, Twitter, mailing lists, blog and other channels will assist in educating Cartographer users and rolling out the patched release to affected users.
 
 The Security Team will also publish any mitigating steps users can take until the fix can be applied to their Cartographer instances. Cartographer distributors will handle creating and publishing their own security advisories.
 
 ## Mailing lists
 
 *   Use security@vmware.com to report security concerns to the VMware Security Team, who uses the list to privately discuss security issues and fixes prior to disclosure.
-*   Join the [Cartographer Distributors](<DISTRIBUTORS EMAIL LINK>) mailing list for early private information and vulnerability disclosure. Early disclosure may include mitigating steps and additional information on security patch releases. See below for information on how Cartographer distributors or vendors can apply to join this list.
+*   Join the [Cartographer Distributors](cartographer-distributors@googlegroups.com) mailing list for early private information and vulnerability disclosure. Early disclosure may include mitigating steps and additional information on security patch releases. See below for information on how Cartographer distributors or vendors can apply to join this list.
 
 ## Early Disclosure to Cartographer Distributors List
 
 The private list is intended to be used primarily to provide actionable information to multiple distributor projects at once. This list is not intended to inform individuals about security issues.
 
 ## Membership Criteria
 
-To be eligible to join the [Cartographer Distributors](<DISTRIBUTORS EMAIL LINK>) mailing list, you should:
+To be eligible to join the [Cartographer Distributors](cartographer-distributors@googlegroups.com) mailing list, you should:
 
 1. Be an active distributor of Cartographer.
 2. Have a user base that is not limited to your own organization.
@@ -87,7 +87,7 @@ In the unfortunate event that you share information beyond what is permitted by
 
 ## Requesting to Join
 
-Send new membership requests to <DISTRIBUTORS EMAIL LINK>. In the body of your request please specify how you qualify for membership and fulfill each criterion listed in the Membership Criteria section above.
+Send new membership requests to cartographer-distributors@googlegroups.com. In the body of your request please specify how you qualify for membership and fulfill each criterion listed in the Membership Criteria section above.
 
 
 ## Confidentiality, integrity and availability

GOVERNANCE.md

@@ -0,0 +1,46 @@
+
+# Cartographer Governance
+
+This document defines the project governance for Cartographer, an open source project by VMware.
+
+## Overview
+
+Cartographer is a Kubernetes native Choreographer. It allows users to configure K8s resources into re-usable [_Supply Chains_](site/content/docs/reference.md#ClusterSupplyChain) that can be used to define all of the stages that an [_Application Workload_](site/content/docs/reference.md#Workload) must go through to get to an environment. 
+
+We are committed to the project not only delivering the distribution, but also building an open, inclusive, and productive open, inclusive, and productive vendor driven open source community; together, we will advance a reliable, nimble, and extensible foundation for modern applications.
+
+## Community
+
+Users: Members who engage with the Cartographer community, providing valuable feedback and unique perspectives.
+
+Contributors: Members who contribute to the project through documentation, code reviews, responding to issues, participation in RFC discussions, contributing code, etc. The project welcomes code contributions to the Cartographer project, as well as contributor-originated packages that add capabilities from other projects. These contributed packages will conform to the Cartographer packaging requirements and lifecycle management.
+
+Maintainers: Given the nature of this project and its relationship to VMware’s Tanzu product offerings, the Cartographer project leaders are current employees of VMware. They are responsible for the overall health and direction of the project; final reviewers of PRs and responsible for releases. Some maintainers are responsible for one or more components within a project, acting as technical leads for that component. Maintainers are expected to contribute code and documentation, review PRs including ensuring quality of code, triage issues, proactively fix bugs, and perform maintenance tasks for these components. If a maintainer leaves VMware, they will also leave their maintainer position.
+
+## Request for Change (RFC) Process
+
+One of the most important aspects in any open source community is the concept of RFCs. All large changes to the codebase and/or new features, including ones proposed by maintainers, should be preceded by an RFC in this repository. This process allows for all members of the community to weigh in on the concept (including the technical details), share their comments and ideas, and offer to help. It also ensures that members are not duplicating work or inadvertently stepping on toes by making large conflicting changes.
+
+The project roadmap is defined by accepted RFCs.
+
+RFCs should cover the high-level objectives, use cases, and technical recommendations on how to implement. In general, the community member(s) interested in implementing the RFC should be either deeply engaged in the RFC process or be an author of the RFC.
+
+The RFC should be documented as a separated markdown in the Cartographer repository via PR.
+Use the RFC Template as a starting point.
+
+## RFC Lifecycle
+
+The RFC PR follows the GitHub lifecycle of the PR to indicate its status:
+
+Open: RFC is created and under review and discussion.
+
+Merged: RFC has been reviewed and is accepted, and labeled “accepted” for tracking purposes.
+
+Closed: RFC has been reviewed and was rejected, and labeled “rejected” for tracking purposes.
+
+## Lazy Consensus
+
+To maintain velocity in a project as busy as Cartographer, the concept of Lazy Consensus is practiced. Ideas and / or RFCs should be shared by maintainers via GitHub with the appropriate maintainer groups (e.g., @vmware-tanzu/cartographer-maintainers) tagged. Out of respect for other contributors, major changes should also be accompanied by a ping on Slack, and a note on the Cartographer mailing list as appropriate. Author(s) of RFCs, pull requests, issues, etc. will specify a time period of no less than five (5) working days for comment and remain cognizant of popular observed world holidays.
+Other maintainers may request additional time for review, but should avoid blocking progress and abstain from delaying progress unless absolutely needed. The expectation is that blocking progress is accompanied by a guarantee to review and respond to the relevant action(s) (RFCs, PRs, issues, etc.) in short order. All pull requests need to be approved by two (2) maintainers.
+
+Lazy Consensus is practiced for the main project repository and the additional repositories listed above.