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

1 files changed, 93 insertions, 1 deletions

diff --git a/github-management/org-owners-guide.md b/github-management/org-owners-guide.md
index 476c71f5..272c7cea 100644
--- a/github-management/org-owners-guide.md
+++ b/github-management/org-owners-guide.md
@@ -41,7 +41,8 @@ managed by the Kubernetes project or use a different name.
 
 Due to licensing and CLA issues, prior to transferring software into a
 Kubernetes managed organization there is some due diligence that needs to occur.
-Please contact the steering committee and CNCF prior to moving any code in.
+If needed, please contact the steering committee and CNCF prior to moving any
+code in.
 
 It is easier to start new code in a Kubernetes organization than it is to
 transfer in existing code.
@@ -137,7 +138,98 @@ checking on all contributions. For more details on those please see the
 Project](https://github.com/kubernetes/kubernetes-template-project), and the
 [Repository Guidelines](kubernetes-repositories.md)
 
+The process for creating and removing new repositories is detailed below.
+
+### Creating Repositories
+
+#### Non-staging repositories
+
+For non-staging repositories, suggestions on how to create
+a new repository are described below.
+
+  * Ensure that the repo creation request has appropriate approvals
+  as per the rules mentioned above.
+  * Using the organization and repository name mentioned in the repo creation
+  request, create a new repo with:
+    * The [kubernetes-template-project] repo as the [template repo]
+    * `Description` as mentioned in the repo creation request
+  * Clone the newly created repo locally.
+  * Make the following changes:
+    * If the request references a team to be listed in the `OWNERS`
+    file, update the `OWNERS_ALIASES` file to remove the steering-committee
+    alias and add a new alias for the team with members populated as per the
+    GitHub team. If the request does not reference a team, remove the
+    `OWNERS_ALIASES` file.
+    * Update the OWNERS file as per the request. If the repo is a
+    [SIG Repository], add a labels entry for the SIG that the repo belongs to.
+    * Update the `SECURITY_CONTACTS` file as per the request. Note that aliases
+    cannot be used in this case so expand the team, if specified.
+    * Create a new commit with the message *Update OWNERS, OWNERS_ALIASES and
+    SECURITY_CONTACTS*.
+  * Push the new commit directly to the master branch.
+  * If the repo is a [SIG Repository], add a new topic of the form
+  `k8s-sig-<sig-name-repo-belongs-to>` using the *Manage Topics* option.
+  * Create a PR against [kubernetes/org] to add teams as per the [team guidance](#team-guidance)
+  for alloting repo admin and write access.
+  * Once the above PR is merged and the postsubmit has run, the new GitHub teams
+  will be created. In the *Collaborators and Teams* section in Settings,
+  assign the new teams appropriate access to the repo.
+  * Ask the author of the repo creation request to add the repo
+  as a part of a subproject in [`sigs.yaml`](/sigs.yaml).
+
+#### Staging Repositories
+
+If the repository is a staging repository, there are some deviations
+from the above procedure:
+
+  * The repository **must** have an initial empty commit. The contents of the
+  repo will be populated from staging by the [publishing-bot].
+  * Grant the [@kubernetes/stage-bots] team admin access to the repo.
+  * Setup branch protection and enable access to the
+  `stage-bots` team by adding the repo in
+  [`prow/config.yaml`](https://git.k8s.io/test-infra/prow/config.yaml). See
+  [kubernetes/test-infra#9292](https://github.com/kubernetes/test-infra/pull/9292)
+  for an example.
+  * Once the repo has been created, add the repo to
+  [`hack/fetch-all-latest-and-push.sh`](https://git.k8s.io/publishing-bot/hack/fetch-all-latest-and-push.sh)
+  in the [publishing-bot] repo.
+
+<!-- TODO: Add suggestions for how to migrate existing repos -->
+
+### Removing Repositories
+
+When a repository has been deemed eligible for removal, we take the following
+steps:
+
+  * 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
+  * Remove all teams associated with the repo
+  * The repo is marked as archived using [GitHub's archive feature]
+  * Remove the repo from [sigs.yaml]
+  * The removal is announced on the kubernetes-dev mailing list and community
+    meeting
+
+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.
+
+In case a repository has only the initial commits adding template files
+and no additional activity, it can be completely deleted.
+
 [GitHub Administration Team]:
 /github-management/README.md#github-administration-team
+[GitHub's archive feature]:
+https://help.github.com/articles/archiving-a-github-repository/
 [@kubernetes/owners]: https://github.com/orgs/kubernetes/teams/owners
 [kubernetes/org]: https://github.com/kubernetes/org
+[publishing-bot]: https://github.com/kubernetes/publishing-bot
+[@kubernetes/stage-bots]: https://github.com/orgs/kubernetes/teams/stage-bots
+[kubernetes-retired]: https://github.com/kubernetes-retired
+[kubernetes-template-project]: https://github.com/kubernetes/kubernetes-template-project
+[SIG Repository]: /github-management/kubernetes-repositories.md##sig-repositories
+[template repo]: https://help.github.com/en/articles/creating-a-repository-from-a-template