-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
updating governance for Velero - WIP #2541
Merged
Merged
Changes from all commits
Commits
Show all changes
10 commits
Select commit
Hold shift + click to select a range
fbdb774
Update _template.md
michmike a5486d2
Create GOVERNANCE.md
michmike cd9509b
Create MAINTAINERS.md
michmike 893b8b3
Update GOVERNANCE.md
michmike 2234ff5
Update GOVERNANCE.md
michmike a860792
Update MAINTAINERS.md
michmike f330f3a
Update _template.md
michmike 4a61100
Update GOVERNANCE.md
michmike d3edc44
Update GOVERNANCE.md
michmike 75185bf
Update MAINTAINERS.md
michmike File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,112 @@ | ||
# Velero Governance | ||
|
||
This document defines the project governance for Velero. | ||
|
||
## Overview | ||
|
||
**Velero**, an open source project, is committed to building an open, inclusive, productive and self-governing open source community focused on building a high quality tool that enables users to safely backup and restore, perform disaster recovery, and migrate Kubernetes cluster resources and persistent volumes. The community is governed by this document with the goal of defining how community should work together to achieve this goal. | ||
|
||
## Code Repositories | ||
|
||
The following code repositories are governed by Velero community and maintained under the `vmware-tanzu\Velero` organization. | ||
|
||
* **[Velero](https://github.com/vmware-tanzu/velero):** Main Velero codebase | ||
* **[Helm Chart](https://github.com/vmware-tanzu/helm-charts/tree/master/charts/velero):** The Helm chart for the Velero server component | ||
* **[Velero CSI Plugin](https://github.com/vmware-tanzu/velero-plugin-for-csi):** This repository contains Velero plugins for snapshotting CSI backed PVCs using the CSI beta snapshot APIs | ||
* **[Velero Plugin for vSphere](https://github.com/vmware-tanzu/velero-plugin-for-vsphere):** This repository contains the Velero Plugin for vSphere. This plugin is a volume snapshotter plugin that provides crash-consistent snapshots of vSphere block volumes and backup of volume data into S3 compatible storage. | ||
* **[Velero Plugin for AWS](https://github.com/vmware-tanzu/velero-plugin-for-aws):** This repository contains the plugins to support running Velero on AWS, including the object store plugin and the volume snapshotter plugin | ||
* **[Velero Plugin for GCP](https://github.com/vmware-tanzu/velero-plugin-for-gcp):** This repository contains the plugins to support running Velero on GCP, including the object store plugin and the volume snapshotter plugin | ||
* **[Velero Plugin for Azure](https://github.com/vmware-tanzu/velero-plugin-for-microsoft-azure):** This repository contains the plugins to support running Velero on Azure, including the object store plugin and the volume snapshotter plugin | ||
* **[Velero Plugin Example](https://github.com/vmware-tanzu/velero-plugin-example):** This repository contains example plugins for Velero | ||
|
||
|
||
## Community Roles | ||
|
||
* **Users:** Members that engage with the Velero community via any medium (Slack, GitHub, mailing lists, etc.). | ||
* **Contributors:** Regular contributions to projects (documentation, code reviews, responding to issues, participation in proposal discussions, contributing code, etc.). | ||
* **Maintainers**: The Velero project leaders. 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. | ||
|
||
### Maintainers | ||
|
||
New maintainers must be nominated by an existing maintainer and must be elected by a supermajority of existing maintainers. Likewise, maintainers can be removed by a supermajority of the existing maintainers or can resign by notifying one of the maintainers. | ||
|
||
### Supermajority | ||
|
||
A supermajority is defined as two-thirds of members in the group. | ||
michmike marked this conversation as resolved.
Show resolved
Hide resolved
|
||
A supermajority of [Maintainers](#maintainers) is required for certain | ||
decisions as outlined above. A supermajority vote is equivalent to the number of votes in favor being at least twice the number of votes against. For example, if you have 5 maintainers, a supermajority vote is 4 votes. Voting on decisions can happen on the mailing list, GitHub, Slack, email, or via a voting service, when appropriate. Maintainers can either vote "agree, yes, +1", "disagree, no, -1", or "abstain". A vote passes when supermajority is met. An abstain vote equals not voting at all. | ||
|
||
### Decision Making | ||
|
||
Ideally, all project decisions are resolved by consensus. If impossible, any | ||
maintainer may call a vote. Unless otherwise specified in this document, any | ||
vote will be decided by a supermajority of maintainers. | ||
|
||
Votes by maintainers belonging to the same company | ||
will count as one vote; e.g., 4 maintainers employed by fictional company **Valerium** will | ||
only have **one** combined vote. If voting members from a given company do not | ||
agree, the company's vote is determined by a supermajority of voters from that | ||
company. If no supermajority is achieved, the company is considered to have | ||
abstained. | ||
|
||
## Proposal Process | ||
|
||
One of the most important aspects in any open source community is the concept | ||
of proposals. Large changes to the codebase and / or new features should be | ||
preceded by a proposal in our community repo. 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 proposals. | ||
|
||
Proposals 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 proposal should be either deeply engaged in the | ||
proposal process or be an author of the proposal. | ||
|
||
The proposal should be documented as a separated markdown file pushed to the root of the | ||
`design` folder in the [Velero](https://github.com/vmware-tanzu/velero/tree/master/design) | ||
repository via PR. The name of the file should follow the name pattern `<short | ||
meaningful words joined by '-'>_design.md`, e.g: | ||
`restore-hooks-design.md`. | ||
|
||
Use the [Proposal Template](https://github.com/vmware-tanzu/velero/blob/master/design/_template.md) as a starting point. | ||
|
||
### Proposal Lifecycle | ||
michmike marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
The proposal PR can follow the GitHub lifecycle of the PR to indicate its status: | ||
|
||
* **Open**: Proposal is created and under review and discussion. | ||
* **Merged**: Proposal has been reviewed and is accepted (either by consensus or through a vote). | ||
* **Closed**: Proposal has been reviewed and was rejected (either by consensus or through a vote). | ||
|
||
## Lazy Consensus | ||
michmike marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
To maintain velocity in a project as busy as Velero, the concept of [Lazy | ||
Consensus](http://en.osswiki.info/concepts/lazy_consensus) is practiced. Ideas | ||
and / or proposals should be shared by maintainers via | ||
GitHub with the appropriate maintainer groups (e.g., | ||
`@vmware-tanzu/velero-maintainers`) tagged. Out of respect for other contributors, | ||
major changes should also be accompanied by a ping on Slack or a note on the | ||
Velero mailing list as appropriate. Author(s) of proposal, Pull Requests, | ||
issues, etc. will give a time period of no less than five (5) working days for | ||
comment and remain cognizant of popular observed world holidays. | ||
|
||
Other maintainers may chime in and request additional time for review, but | ||
should remain cognizant of 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) | ||
(proposals, PRs, issues, etc.) in short order. | ||
|
||
Lazy Consensus is practiced for all projects in the `Velero` org, including | ||
the main project repository and the additional repositories. | ||
|
||
Lazy consensus does _not_ apply to the process of: | ||
|
||
* Removal of maintainers from Velero | ||
|
||
## Updating Governance | ||
|
||
All substantive changes in Governance require a supermajority agreement by all maintainers. |
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 |
---|---|---|
@@ -0,0 +1,27 @@ | ||
# Velero Maintainers | ||
|
||
[GOVERNANCE.md](https://github.com/vmware-tanzu/velero/blob/master/GOVERNANCE.md) describes governance guidelines and maintainer responsibilities. | ||
|
||
## Maintainers | ||
|
||
| Maintainer | GitHub ID | Affiliation | | ||
| --------------- | --------- | ----------- | | ||
| Steve Kriss | [skriss](https://github.com/skriss) | [VMware](https://www.github.com/vmware/) | | ||
| Carlisia Campos | [carlisia](https://github.com/carlisia) | [VMware](https://www.github.com/vmware/) | | ||
| Nolan Brubaker | [nrb](https://github.com/nrb) | [VMware](https://www.github.com/vmware/) | | ||
| Ashish Amarnath | [ashish-amarnath](https://github.com/ashish-amarnath) | [VMware](https://www.github.com/vmware/) | | ||
| Stephanie Bauman | [stephbman](https://github.com/stephbman) | [VMware](https://www.github.com/vmware/) | | ||
|
||
## Emeritus Maintainers | ||
michmike marked this conversation as resolved.
Show resolved
Hide resolved
michmike marked this conversation as resolved.
Show resolved
Hide resolved
|
||
* Andy Goldstein ([ncdc](https://github.com/ncdc)) | ||
* Adnan Abdulhussein ([prydonius](https://github.com/prydonius)) | ||
|
||
## Velero Contributors & Stakeholders | ||
|
||
| Feature Area | Lead | | ||
| ----------------------------- | :---------------------: | | ||
| Technical Lead | Steve Kriss (skriss) | | ||
| Kubernetes CSI Liaison | Nolan Brubaker (nrb), Ashish Amarnath (ashish-amarnath) | | ||
| Deployment | Carlisia Campos (carlisia), Carlos Tadeu Panato Junior (cpanato) | | ||
| Community Management | Jonas Rosland (jonasrosland) | | ||
| Product Management | Stephanie Bauman (stephbman) | | ||
michmike marked this conversation as resolved.
Show resolved
Hide resolved
|
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should technical/feature leads be another role, a step forward from Contributors towards becoming a maintainer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you be more specific as to what makes that role more distinct from a contributor or maintainer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is like giving a category to the Feature leads (Stake holders) that are mentioned here: https://github.com/vmware-tanzu/velero/blob/a86079220173c4e7f5f9dead9aa5857ba77ba758/MAINTAINERS.md#velero-contributors--stakeholders
The journey could be:
Contributors -> Leads/Stake holders -> Maintainers
As the load/backlog on the Maintainers increases, Maintainers could nominate one of the Contributors who are familiar with a certain feature/area and have significantly contributed to that area to become a Lead/Stake Holder
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kmova that's a good suggestion. others what do you think?
cc: @vmware-tanzu/velero-maintainers
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is worth talking about "face-to-face" in our community meeting.
Initially my question is, other than on-paper recognition (which I'm all for), how would this role be different than a maintainer, in practical terms?