diff options
| author | Tamer Tas <contact@tmrts.com> | 2016-12-10 18:56:20 +0200 |
|---|---|---|
| committer | Tamer Tas <contact@tmrts.com> | 2016-12-10 18:56:20 +0200 |
| commit | 8e316a36bb28138aa354cbd693c6136d1ad1ca47 (patch) | |
| tree | 05647be40122d8b12d7057ffbb0ab395a74293e6 | |
| parent | 1713f56e908a87f28175dc57d644fcade9a9b498 (diff) | |
governance: include contributor roles inside the organization
| -rw-r--r-- | governance.md | 53 |
1 files changed, 53 insertions, 0 deletions
diff --git a/governance.md b/governance.md index d6f63bb2..30c30a3d 100644 --- a/governance.md +++ b/governance.md @@ -1,3 +1,56 @@ +# Kubernetes Organization Roles + +The following is a list of roles that are currently assumed by different contributors: + +- **[New Contributor](https://github.com/kubernetes/contrib/issues/1090)**: a + couple of PRs +- **Contributor**: more than a couple of PRs (which could include documentation + contributions as well as code) +- **Org Member**: active enough to be useful to assign issues to them and add + them to a github team (e.g., for a SIG) for notification purposes; if they + choose public membership, they get a badge on their github profile +- **kubernetes-collaborators**: "read access" to kubernetes repo; get a badge + on PR and issue comments; trusted enough to run tests on their PRs + automatically; can issue "@k8s-bot ok to test" for other contributors +- **Reviewer**: In some OWNERS file as a reviewer (in repos using the bot), + assigned related PRs, assigned relevant test bugs; can champion incubator + repos +- **Approver**: some OWNERS file as an approver; will be needed to get code + merged +- **SIG Participant**: active in one or more areas of the project; wide + variety of roles are represented +- **SIG lead**: SIG organizer +- **Area/Component Owner**: design/proposal approval authority for some area + of the project, though escalation is still possible, and most beta/GA API + changes are vetted by the API owners +- **API Owners**: lead designers of the project, who are familiar with the + design, requirements, mechanics, conventions, style, scope, gotchas, etc. + of the API +- **Team Lead**: tech lead or manager of some team at some company working on + K8s; can influence priorities of their team members; pragmatically, + probably want label/assignment powers +- **Top-Level OWNERS**: de-facto project elders; technically can + approve virtually any PRs; can sponsor incubator repos +- **kubernetes-maintainers**: write access to repo (assign issues/PRs, + add/remove labels and milestones, edit issues and PRs, edit wiki, + create/delete labels and milestones); technically can lgtm any PR and cause it + to be merged by the submit queue; expected to review PRs and fix bugs related + to their domains +- **kubernetes-project-managers**: help to manage and maintain the project in + ways other than just writing code (e.g. managing issues). +- **kubernetes-admin**: direct code write/merge access; for build cops and + release czars only. +- **Build Cop**: ensure tests pass, submit queue is working, rollback PRs, + manually merge as necessary to fix build +- **User-Support Rotation**: answer questions on stackoverflow, googlegroups, + slack, twitter, etc. full time while on duty +- **Release Czar**: drive release +- **K8s Org Owner**: can create repos, do ~any github action; the number of + owners shouldn't scale with the organization's growth, O(1), and optimally it + should be less than 10 people who are very familiar with project workings and + distributed across a few time zones and organizations The other repos will + have distinct sets of people filling some of the above roles, also. + # Kubernetes SIG Governance In order to standardize Special Interest Group efforts, create maximum transparency, and route contributors to the appropriate SIG, SIGs should follow the guidelines stated below: |
