Merge branch 'master' of https://github.com/kubernetes/community into apireviews

6 files changed, 131 insertions, 45 deletions

diff --git a/github-management/OWNERS b/github-management/OWNERS
index 70807ad1..cab8996b 100644
--- a/github-management/OWNERS
+++ b/github-management/OWNERS
@@ -1,7 +1,13 @@
 reviewers:
+  - calebamiles
   - cblecker
+  - fejta
+  - grodrigues3
+  - idvoretskyi
+  - spiffxp
 approvers:
   - cblecker
+  - grodrigues3
 labels:
   - sig/contributor-experience
   - area/github-management
diff --git a/github-management/README.md b/github-management/README.md
index a15b7a66..043bb5da 100644
--- a/github-management/README.md
+++ b/github-management/README.md
@@ -14,11 +14,36 @@ These polices are overseen by the
 Experience Special Interest Group.
 
 ## Guides
+- [Opening a request for assistance with GitHub](opening-a-request.md)
 - [Organization Owners Guide](org-owners-guide.md)
 - [Repository Creation Guidelines](kubernetes-repositories.md)
 - [Setting up the CNCF CLA Check](setting-up-cla-check.md)
 - [GitHub Permissions](permissions.md)
 
+## GitHub Administration Team
+
+In order to manage the various organizations that the Kubernetes project owns,
+we have a GitHub Administration team that is responsible for carrying out the
+various tasks.
+
+This team (**[@kubernetes/owners](https://github.com/orgs/kubernetes/teams/owners)**) is as follows:
+* Aaron Crickenberger (**[@spiffxp](https://github.com/spiffxp)**, US Pacific)
+* Caleb Miles (**[@calebamiles](https://github.com/calebamiles)**, US Pacific)
+* Christoph Blecker (**[@cblecker](https://github.com/cblecker)**, CA Pacific)
+* Erick Fejta (**[@fejta](https://github.com/fejta)**, US Pacific)
+* Garrett Rodrigues (**[@grodrigues3](https://github.com/grodrigues3)**, US Pacific)
+* Ihor Dvoretskyi (**[@idvoretskyi](https://github.com/idvoretskyi)**, UA Eastern European)
+
+This team is responsible for holding Org Owner privileges over all the active
+Kubernetes orgs, and will take action in accordance with our polices and
+procedures. All members of this team are subject to the Kubernetes
+[security embargo policy](https://git.k8s.io/sig-release/security-release-process-documentation/security-release-process.md#embargo-policy).
+
+Nominations to this team will come from the Contributor Experience SIG, and
+require confirmation by the Steering Committee before taking effect. Time zones
+and country of origin should be considered when selecting membership, to ensure
+sufficient after North American business hours and holiday coverage.
+
 ## Project Owned Organizations
 
 The following organizations are currently known to be part of the Kubernetes
diff --git a/github-management/kubernetes-repositories.md b/github-management/kubernetes-repositories.md
index 7b1faf3b..c1082a6a 100644
--- a/github-management/kubernetes-repositories.md
+++ b/github-management/kubernetes-repositories.md
@@ -1,35 +1,35 @@
-## Kubernetes Repository Guidelines
+# Kubernetes Repository Guidelines
 
 This document attempts to outline a structure for creating and associating GitHub repositories with the Kubernetes project. It also describes how and when
 repositories are removed.
 
 The document presents a tiered system of repositories with increasingly strict requirements in an attempt to provide the right level of oversight and flexibility for a variety of different projects.
 
-### Associated Repositories
+## Associated Repositories
 
 Associated repositories conform to the Kubernetes community standards for a repository, but otherwise have no restrictions. Associated repositories exist solely for the purpose of making it easier for the Kubernetes community to work together. There is no implication of support or endorsement of any kind by the Kubernetes project, the goals are purely logistical.
 
-#### Goals
+### Goals
 
 To facilitate contributions and collaboration from the broader Kubernetes community.  Contributions to random projects with random CLAs (or DCOs) can be logistically difficult, so associated repositories should be easier.
 
 
-#### Rules
+### Rules
 
    * Must adopt the Kubernetes Code of Conduct statement in their repo.
    * All code projects use the Apache License version 2.0. Documentation repositories must use the Creative Commons License version 4.0.
    * Must adopt the CNCF CLA bot automation for pull requests.
 
 
-### SIG repositories
+## SIG repositories
 
 SIG repositories serve as temporary homes for SIG-sponsored experimental projects or prototypes of new core functionality, or as permanent homes for SIG-specific tools.
 
-#### Goals
+### Goals
 
 To provide a place for SIGs to collaborate on projects endorsed by and actively worked on by members of the SIG. SIGs should be able to approve and create new repositories for SIG-sponsored projects without requiring higher level approval from a central body (e.g. steering committee or sig-architecture)
 
-#### Rules for new repositories
+### Rules for new repositories
 
    * For now all repos will live in github.com/kubernetes-sigs/\<project-name\>.
    * Must contain the topic for the sponsoring SIG - e.g. `k8s-sig-api-machinery`.  (Added through the *Manage topics* link on the repo page.)
@@ -40,7 +40,7 @@ To provide a place for SIGs to collaborate on projects endorsed by and actively
    * SIG membership must vote using lazy consensus to create a new repository
    * SIG must already have identified all of their existing subprojects and code, with valid OWNERS files, in [`sigs.yaml`](https://github.com/kubernetes/community/blob/master/sigs.yaml)
 
-#### Rules for donated repositories
+### Rules for donated repositories
 
 The `kubernetes-sigs` organization is primarily intended to house net-new
 projects originally created in that organization. However, projects that a SIG
@@ -55,14 +55,14 @@ In addition to the requirements for new repositories, donated repositories must
    * Licenses of dependencies are acceptable; project owners can ping [@caniszczyk](https://github.com/caniszczyk) for review of third party deps
    * Boilerplate text across all files should attribute copyright as follows: `"Copyright <Project Authors>"` if no CLA was in place prior to donation
 
-### Core Repositories
+## Core Repositories
 
 Core repositories are considered core components of Kubernetes. They are utilities, tools, applications, or libraries that are expected to be present in every or nearly every Kubernetes cluster, such as components and tools included in official Kubernetes releases. Additionally, the kubernetes.io website, k8s.io machinery, and other project-wide infrastructure will remain in the kubernetes github organization.
 
-#### Goals
+### Goals
 Create a broader base of repositories than the existing gh/kubernetes/kubernetes so that the project can scale. Present expectations about the centrality and importance of the repository in the Kubernetes ecosystem. Carries the endorsement of the Kubernetes community.
 
-#### Rules
+### Rules
 
    * Must live under `github.com/kubernetes/<project-name>`
    * Must adopt the Kubernetes Code of Conduct
@@ -72,7 +72,7 @@ Create a broader base of repositories than the existing gh/kubernetes/kubernetes
    * All OWNERS must be members of standing as defined by ability to vote in Kubernetes steering committee elections. in the Kubernetes community
    * Repository must be approved by SIG-Architecture
 
-### Removing Repositories
+## Removing Repositories
 
 As important as it is to add new repositories, it is equally important to
 prune old repositories that are no longer relevant or useful.
@@ -85,72 +85,68 @@ wide processes, it ensures a rapid response to potential required fixes
 contributors and users receive quick feedback on their issues and
 contributions.
 
-#### Grounds for removal
+### Grounds for removal
+
 SIG repositories and core repositories may be removed from the project if they
 are deemed _inactive_. Inactive repositories are those that meet any of the
 following criteria:
 
    * There are no longer any active maintainers for the project and no
-replacements can be found.
+     replacements can be found.
    * All PRs or Issues have gone un-addressed for longer than six months.
    * There have been no new commits or other changes in more than a year.
+   * The contents have been folded into another actively maintained project.
 
 Associated repositories are much more loosely associated with the Kubernetes
 project and are generally not subject to removal, except under exceptional
 circumstances (e.g. a code of conduct violation).
 
+### Procedure for removal
 
-#### Procedure for removal
-When a repository is set for removal, it is moved into the
-[kubernetes-retired](https://github.com/kubernetes-retired) organization.
-This maintains the
-complete record of issues, PRs and other contributions, but makes it clear
-that the repository should be considered archival, not active. We will also
-use the [github archive feature](https://help.github.com/articles/archiving-a-github-repository/) to mark the repository as archival and read-only.
-
-The decision to archive a repository will be made by SIG architecture and
-announced on the Kubernetes dev mailing list and community meeting.
+When a repository has been deemed eligible for removal, we take the following steps:
 
-### FAQ
+    * Ownership of the repo is transferred to the [kubernetes-retired] GitHub organization
+    * The repo description is edited to start with the phrase "[EOL]"
+    * All open issues and PRs are closed
+    * All external collaborators are removed
+    * All webhooks, apps, integrations or services are removed
+    * GitHub Pages are disabled
+    * The repo is marked as archived using [GitHub's archive feature]
+    * The removal is announced on the kubernetes-dev mailing list and community meeting
 
-*My project is currently in kubernetes-incubator, what is going to happen to it?*
+This maintains the complete record of issues, PRs and other contributions,
+leaves the repository read-only, and makes it clear that the repository
+should be considered retired and unmaintained.
 
-Nothing. We’ll grandfather existing projects and they can stay in the incubator org for as long as they want to. We expect/hope that most projects will either move out to ecosystem, or into SIG or Core repositories following the same approval process described below.
+## FAQ
 
+**My project is currently in kubernetes-incubator, what is going to happen to it?**
 
+Nothing. We’ll grandfather existing projects and they can stay in the incubator org for as long as they want to. We expect/hope that most projects will either move out to ecosystem, or into SIG or Core repositories following the same approval process described below.
 
-*My project wants to graduate from incubator, how can it do that?*
+**My project wants to graduate from incubator, how can it do that?**
 
 Either approval from a SIG to graduate to a SIG repository, or approval from SIG-Architecture to graduate into the core repository.
 
-
-
-*My incubator project wants to go GA, how can it do that?*
+**My incubator project wants to go GA, how can it do that?**
 
 For now, the project determines if and when it is GA. For the future, we may define a cross Kubernetes notion of GA for core and sig repositories, but that’s not in this proposal.
 
-
-
-*My project is currently in core, but doesn’t seem to fit these guidelines, what’s going to happen?*
+**My project is currently in core, but doesn’t seem to fit these guidelines, what’s going to happen?**
 
 For now, nothing. Eventually, we may redistribute projects, but for now the goal is to adapt the process going forward, not re-legislate past decisions.
 
-
-
-*I’m starting a new project, what should I do?*
+**I’m starting a new project, what should I do?**
 
 Is this a SIG-sponsored project? If so, convince some SIG to host it, take it to the SIG mailing list, meeting and get consensus, then the SIG can create a repo for you in the SIG organization.
 
-
-
 Is this a small-group or personal project? If so, create a repository wherever you’d like, and make it an associated project.
 
-
-
 We suggest starting with the kubernetes-template-project to ensure you have the correct code of conduct, license, etc.
 
-
-
-*Much of the things needed (e.g. CLA Bot integration) is missing to support associated projects. Many things seem vague. Help!*
+**Much of the things needed (e.g. CLA Bot integration) is missing to support associated projects. Many things seem vague. Help!**
 
 True, we need to improve these things. For now, do the best you can to conform to the spirit of the proposal (e.g. post the code of conduct, etc)
+
+[GitHub's archive feature]: https://help.github.com/articles/archiving-a-github-repository/
+[kubernetes-retired]: https://github.com/kubernetes-retired
diff --git a/github-management/opening-a-request.md b/github-management/opening-a-request.md
new file mode 100644
index 00000000..b0088647
--- /dev/null
+++ b/github-management/opening-a-request.md
@@ -0,0 +1,33 @@
+# Opening a issue for support with GitHub
+
+## GitHub issues
+
+If you need help with the following:
+- Permissions issues
+- Organization membership
+- Third-party integrations
+- Webhooks
+- Repository creation/migration
+- Repository archival
+- Other repository and configuration issues
+
+Please open an issue against the [kubernetes/org] repository describing your
+issue. If your request is urgent, please escalate to **[@kubernetes/owners]**.
+
+## Bot/Automation issues
+
+If you need help with the following:
+- Bot configuration
+- Automatic merging
+- Issue labelling
+- Automation feedback and feature requests
+
+Please open an issue against the [kubernetes/test-infra] repository describing
+your issue. If your request is urgent, please escalate to the
+[test-infra on-call] or reach out to `#testing-ops` on Slack.
+
+
+[kubernetes/org]: https://github.com/kubernetes/org/issues
+[@kubernetes/owners]: https://github.com/orgs/kubernetes/teams/owners
+[kubernetes/test-infra]: https://github.com/kubernetes/test-infra/issues
+[test-infra on-call]: https://go.k8s.io/oncall
diff --git a/github-management/org-owners-guide.md b/github-management/org-owners-guide.md
index ad7c8a7e..0ac510d9 100644
--- a/github-management/org-owners-guide.md
+++ b/github-management/org-owners-guide.md
@@ -4,6 +4,26 @@ The Kubernetes project leverages multiple GitHub organizations to store and
 organize code. This guide contains the details on how to run those organizations
 for CNCF compliance and for the guidelines of the community.
 
+## SLOs
+
+The [GitHub Administration Team] will aim to handle requests in the following
+time frames:
+- Organization invites should be handled within 72 hours of all requirements for
+  membership being met (all +1s obtained).
+- Repository creation or migration requests should be responded to within 72
+  hours of the issue being opened. There may be information required or specific
+  requirements that take additional time, but once all requirements are met, the
+  repo should be created within 72 hours.
+- Security or moderation requests should be handled ASAP, and coverage should be
+  provided in multiple time zones and countries.
+- All other requests should be responded to within 72 hours of the issue being
+  opened. The time to resolve these requests will vary depending on the
+  specifics of the request.
+
+If a request is taking longer than the above time frames, or there is a need to
+escalate an urgent request, please mention **[@kubernetes/owners]** on the
+associated issue for assistance.
+
 ## Organization Naming
 
 Kubernetes managed organizations should be in the form of `kubernetes-[thing]`.
@@ -60,3 +80,7 @@ for all orgs going forward.  Notable discrepancies at the moment:
 Repositories have additional guidelines and requirements, such as the use of
 CLA checking on all contributions. For more details on those please see the
 [Kubernetes Template Project](https://github.com/kubernetes/kubernetes-template-project), and the [Repository Guidelines](kubernetes-repositories.md)
+
+
+[GitHub Administration Team]: /github-management/README.md#github-administration-team
+[@kubernetes/owners]: https://github.com/orgs/kubernetes/teams/owners
diff --git a/github-management/permissions.md b/github-management/permissions.md
index 3ae03c70..ba036fee 100644
--- a/github-management/permissions.md
+++ b/github-management/permissions.md
@@ -36,7 +36,8 @@ There are certain actions that require org owner access:
 - Transfer repositories
 - Approve GitHub application integrations
 
-**// TODO(cblecker):** Define specific roles that need this.
+In the Kubernetes project, this role is held by the
+[GitHub Administration Team].
 
 ### Member
 
@@ -93,6 +94,7 @@ member in the organization.
 
 [bot commands]: https://go.k8s.io/bot-commands
 [community membership]: /community-membership.md
+[GitHub Administration Team]: /github-management/README.md#github-administration-team
 [org permissions]:
 https://help.github.com/articles/permission-levels-for-an-organization/
 [OWNERS]: /contributors/guide/owners.md