Bootstrap governance

GOVERNANCE.md

@@ -1,31 +1,56 @@
-# Project Governance
+# KCP Project Governance
 
-This is an example governance document for projects that use the very common
-"maintainer council" system of governance.  See [GOVERNANCE.md](/GOVERNANCE.md)
-for more information.  Thanks to the Jaeger Project for portions of the text
-below.
-
-This is a template document for CNCF projects that requires editing
-before it is ready to use. Read the markdown comments, `<!-- COMMENT -->`, for
-additional guidance. The raw markdown uses `TODO` to identify areas that
-require customization.  Replace [TODO: PROJECTNAME] with the name of your project.
+The KCP project is dedicated to democratizing Control Planes beyond container 
+orchestration. This governance explains how the project is run.
 
+- [Manifesto](#values)
+- [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)
+- [Modifying this Charter](modifying-this-charter)
+
+## Manifesto
+
+ * KCP Maintainers strive to be good citizens in the Kubernetes project.
+ * KCP Maintainers see KCP always as part of the Kubernetes ecosystem and always 
+   strive to keep that ecosystem united. In particular, this means:
+   * KCP strives to not divert from Kubernetes, but strives to extend its 
+     use-cases to non-container control planes while keeping the ecosystems of 
+     libraries and tooling united.
+   * KCP – as a consumer of Kubernetes API Machinery – will strive to stay 100% 
+     compatible with the semantics of Kubernetes APIs, while removing container 
+     orchestration specific functionality.
+   * KCP strives to upstream changes to Kubernetes code as much as possible.
+
+## Values
+
+The KCP 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
 
-[TODO: PROJECTNAME] Maintainers have write access to the [project GitHub repository](TODO).
+KCP Maintainers have write access to the [project GitHub repository](https://github.com/kcp-dev/kcp).
 They can merge their own patches or patches from others. The current maintainers
-can be found in [OWNERS](./OWNERS).  Maintainers collectively manage the project's
-resources and contributors.
+can be found as top-level approvers in [OWNERS](./OWNERS).  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 [TODO: PROJECTNAME] project and want to help it grow and
+are people who care about the KCP 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
@@ -34,6 +59,9 @@ 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
 
 <!-- If you have full Contributor Ladder documentation that covers becoming
@@ -44,41 +72,55 @@ To become a Maintainer you need to demonstrate the following:
 
   * commitment to the project:
     * participate in discussions, contributions, code and documentation reviews
-      for [TODO: Time Period] or more,
-    * perform reviews for [TODO:Number] non-trivial pull requests,
-    * contribute [TODO:Number] non-trivial pull requests and have them merged,
+      for 3 months or more,
+    * perform reviews for 5 non-trivial pull requests,
+    * contribute 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.
   <!-- add any additional Maintainer requirements here -->
 
 A new Maintainer must be proposed by an existing maintainer by sending a message to the
-[developer mailing list](TODO: List Link). A simple majority vote of existing Maintainers
-approves the application.
+[developer mailing list](https://groups.google.com/g/kcp-dev). A simple majority 
+vote of existing Maintainers approves the application.
 
 Maintainers who are selected will be granted the necessary GitHub rights,
-and invited to the [private maintainer mailing list](TODO).
+and invited to the [private maintainer mailing list](https://groups.google.com/g/kcp-dev-private).
 
-## Meetings
+### Bootstrapping Maintainers
+
+To bootstrap the process, 3 maintainers are defined (in the initial PR adding 
+this to the repository) that do not necessarily follow the above rules. When a 
+new maintainer is added following the above rules, the existing maintainers 
+define one not following the rules to step down, until all of them follow the 
+rules.
+
+### 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.
 
-Time zones permitting, Maintainers are expected to participate in the public
-developer meeting, which occurs
-[TODO: Details of regular developer or maintainer meeting here].  
+A Maintainer may be removed at any time by a 2/3 vote of the remaining maintainers.
 
-Maintainers will also 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.
+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.
 
-## CNCF Resources
 
-Any Maintainer may suggest a request for CNCF resources, either in the
-[mailing list](TODO: link to developer/maintainer mailing list), 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.
+## Meetings
+
+Time zones permitting, Maintainers are expected to participate in the public 
+community call meeting. Maintainers will also 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.
 
 ## Code of Conduct
 
@@ -88,19 +130,33 @@ to the private Maintainer mailing list or alias in the code-of-conduct file.-->
 
 [Code of Conduct](./code-of-conduct.md)
 violations by community members will be discussed and resolved
-on the [private Maintainer mailing list](TODO).  If the reported CoC violator
-is a Maintainer, the Maintainers will instead designate two Maintainers to work
-with CNCF staff in resolving the report.
+on the [private Maintainer mailing list](https://groups.google.com/g/kcp-dev-private).
+
+## 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 [TODO: PROJECTNAME] is conducted by "lazy consensus", periodically
+While most business in KCP is conducted by "lazy consensus", periodically
 the Maintainers may need to vote on specific actions or changes.
-A vote can be taken on [the developer mailing list](TODO) or
-[the private Maintainer mailing list](TODO) for security or conduct matters.  
-Votes may also be taken at [the developer meeting](TODO).  Any Maintainer may
-demand a vote be taken.
+A vote can be taken on [the developer mailing list](https://groups.google.com/g/kcp-dev) or
+[the private Maintainer mailing list](https://groups.google.com/g/kcp-dev-private)
+for security or conduct matters.  Votes may also be taken at the community call 
+meeting. Any Maintainer may demand a vote be taken.
 
 Most votes require a simple majority of all Maintainers to succeed. Maintainers
 can be removed by a 2/3 majority vote of all Maintainers, and changes to this
-Governance require a 2/3 vote of all Maintainers.
+Governance require a 2/3 vote of all Maintainers.
+
+## Modifying this Charter
+
+Changes to this Governance and its supporting documents may be approved by a 
+2/3 vote of the Maintainers.

OWNERS

@@ -1,5 +1,4 @@
 approvers:
-- ncdc
+- clubanderson
+- scheeles
 - sttts
-- stevekuznetsov
-- davidfestal

SECURITY.md

@@ -0,0 +1,3 @@
+# Security Process for KCP
+
+TBD