governance: include contributor roles inside the organization

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: