-
Notifications
You must be signed in to change notification settings - Fork 23
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
ce0b881
commit 16c9be4
Showing
2 changed files
with
4 additions
and
105 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,104 +1,3 @@ | ||
| # CDEvents Bootstrap Governance | ||
| # CDEvents Governance | ||
|
|
||
| The initial bootstrap committee will consist of 5 individuals who are core stakeholders and/or contributors. | ||
|
|
||
| Members are (in alphabetical order): | ||
|
|
||
| * Emil Bäckmark, [@e-backmark-ericsson](https://github.com/e-backmark-ericsson), Ericsson | ||
| * Andrea Frittoli, [@afrittoli](https://github.com/afrittoli), IBM | ||
| * Mattias Linnér, [@m-linner-ericsson](https://github.com/m-linner-ericsson), Ericsson | ||
| * Erik Sternerson [@erkist](https://github.com/erkist), doWhile | ||
| * Steve Taylor [@sbtaylor15](https://github.com/sbtaylor15), [DeployHub](https://www.deployhub.com) / [Ortelius OS](https://ortelius.io) | ||
|
|
||
| The committee MUST: | ||
|
|
||
| * Represent a cross-section of interests, not just one company | ||
| * Balance technical, architectural, and governance expertise since its initial mission is the establishment of structure around contributions, community, and decision-making | ||
| * Hold staggered terms, sufficient to ensure an orderly transition of power via elections as designed and implemented by the committee (see below for specific deliverables) | ||
| * Provide designated alternates in cases where quorum is required but not attainable with the current set of members | ||
| * Communicate with the Continuous Delivery Foundation on a regular cadence | ||
|
|
||
| ## Committee Deliverables | ||
|
|
||
| The committee will be responsible for a series of specific artifacts and activities as outlined below. | ||
|
|
||
| ### Initial Charter | ||
|
|
||
| This document will define how the committee is to manage the project until it has transitioned to an elected steering body, as well as what governance must be in place. | ||
| The Kubernetes Steering Committee Charter Draft serves as a good example. | ||
|
|
||
| A charter should cover all of the following topics: | ||
|
|
||
| * Scope of rights and responsibilities explicitly held by the committee | ||
| * Committee structure that meets the requirements above | ||
| * Election process, including: | ||
| * special elections in the case someone resigns or is impeached | ||
| * who is eligible to nominate candidates and how | ||
| * who is eligible to run as a candidate | ||
| * Voter registration and requirements | ||
| * election mechanics such as | ||
| * committee company representation quotas | ||
| * Limits on electioneering | ||
| * Responses to election fraud | ||
| * How are changes to the charter enacted, and by what process | ||
| * How are meetings conducted | ||
| * Recorded or not, and if not, how is the information shared | ||
| * How is work tracked? Example steering project board | ||
| * Is there a member note taker, or is there a neutral facilitator role that exists outside of the committee? | ||
| * Frequency, duration, and required consistency | ||
| * Committee decision-making process, and specifically those areas of action that require more/less consensus, e.g. modifications the charter | ||
| * Sub-Steering Committee governance structure (see this example) | ||
|
|
||
| ## Transition Process | ||
|
|
||
| The transition process MUST: | ||
|
|
||
| * Organize, execute, and validate an election for replacing bootstrap members (they may re-run, but would need to be re-elected in order to stay) | ||
| * Define the term lengths for newly-elected individuals, ideally so not all members change out at once | ||
| * Provide documentation for the community and committee members sufficient to smoothly continue the established practices of the committee | ||
|
|
||
| ## Contribution Process | ||
|
|
||
| The committee MUST define a contribution process that: | ||
|
|
||
| * Explains to potential contributors how/if they can add code to the repository/repositories | ||
| * Documents Workflow and management of pull requests | ||
| * Identifies who is authorized to commit or revert code | ||
| * Identifies automation is required for normal operations | ||
| * Defines how release decisions are made | ||
| * Who is authorized to release and when. | ||
| * Frequency limits | ||
| * Defines the documentation process | ||
| * Defines what Contributor License Agreement (CLA) process is required and how it is programmatically enforced before code is merged | ||
|
|
||
| ### Security/Vulnerability Reporting and Response Process | ||
|
|
||
| * Identify and document where vulnerability reporting can be done to the project | ||
| * Identify and document who is responsible for receiving vulnerability reports | ||
| * Document process responsible parties go through to triage and determine veracity of vulnerability | ||
| * Document process for facilitating fix, generating release update, and communicating vulnerability and fix to public | ||
|
|
||
| ## Code of Conduct | ||
|
|
||
| The code of conduct MUST set expectations for contributors on expected behavior, as well as explaining the consequences of violating the terms of the code. | ||
| The [Contributor Covenant](https://www.contributor-covenant.org) has become the de facto standard for this language. | ||
|
|
||
| Members of the governance committee will be responsible for handling [CDEvents code of conduct](code-of-conduct.md) | ||
| violations via cdevents-code-of-conduct@googlegroups.com. | ||
|
|
||
| ## Project Communication Channels | ||
|
|
||
| What are the primary communications channels the project will adopt and manage? | ||
| This can include Slack, mailing lists, an organized Stack Overflow topic, or exist only in GitHub issues and pull requests. | ||
|
|
||
| * Mailing list: [groups.google.com/g/cdevents-dev](https://groups.google.com/g/cdevents-dev). | ||
| * Slack: #sig-events [slack channel](https://cdeliveryfdn.slack.com/archives/C0151BTKEJX) on the CDF slack. | ||
|
|
||
| Governance decisions, votes and questions should take place on the cdevents-governance@googlegroups.com mailing list. | ||
|
|
||
| ## Permissions and access | ||
|
|
||
| Members of the governing board will be given access to these resources: | ||
|
|
||
| * Google Groups Administrators | ||
| * [GitHub Org](https://github.com/cdevents) Administrators | ||
| The governance for the CDEvents project is [documented in the community repository](https://github.com/cdevents/community/blob/main/governance.md). |