Add docs on creating sandbox repos (#125)

* Add docs on creating sandbox repos

* Address one comment from mattmoor

* Make it clear that the link points to automation instructions

* Address vaikas and duglin comments

* Add issue templates and update repo creation directions

* mattmoor-bot

* Add additional examples and notes for repo setup.

.github/ISSUE_TEMPLATE/new-repo.md

@@ -0,0 +1,36 @@
+---
+name: Request a new repo
+about: Request creation of a new repo in the knative or knative-sandbox orgs
+title: "New Repo: $REPONAME"
+---
+
+Use this issue type to request a new repo in `knative-sandbox` (or
+`knative`, which may require additional discussion).
+
+<!-- Update the information below with your request -->
+
+## Repo information
+
+Org: knative-sandbox
+
+Repo:
+
+Purpose (Description):
+
+Sponsoring WG:
+
+## Actions to fulfil
+
+This area is used for the TOC to track the [repo creation
+process](/mechanics/CREATING-A-SANDBOX-REPO.md)
+
+- [ ] Create a new repo in Github UI, with "Apache License 2.0"
+- [ ] Create an OWNERS and README.md file
+- [ ] Add entries in `/peribolos/knative-sandbox.yaml`
+- [ ] (golang) [Add aliases](https://github.com/knative/website) for
+  `knative.dev`
+- [ ] Set up [test-infra](https://github.com/knative/test-infra) following the
+  docs linked at the beginning.
+- [ ] Create a PR with a `CODE-OF-CONDUCT.md` to verify Prow.
+- [ ] Once Prow is enabled and PR checks are passing, add branch protection rules.
+

.github/ISSUE_TEMPLATE/process.md

@@ -0,0 +1,13 @@
+---
+name: Process proposal
+about: Propose a new process or change to existing Knative process
+title: "PROCESS CHANGE: "
+---
+
+Things to include with your process proposal (delete this text):
+
+* Expected benefits. Who gains the benefits? Why will they benefit?
+* Expected costs. Who bears the costs? How heavy are they?
+* Timeframe for implementation / rollout.
+* Are you willing to drive the process, or is this a request for help?
+

.github/ISSUE_TEMPLATE/question.md

@@ -0,0 +1,5 @@
+---
+name: Question
+about: Question for TOC or Steering Committee
+title: ""
+---

mechanics/CREATING-A-SANDBOX-REPO.md

@@ -0,0 +1,95 @@
+---
+title: "Creating a sandbox repo"
+linkTitle: "Sandbox repo process"
+weight: 30
+type: "docs"
+---
+
+<!-- NOTE: some portion of this document is also reproduced in
+/.github/ISSUE_TEMPLATES/new-repo.md. If you are updating the steps here, you
+may need to look there, too. -->
+
+# Background
+
+The [`knative-sandbox`](https://github.com/knative-sandbox) GitHub org exists to
+hold "non-core" Knative components which are owned and sponsored by a Working
+Group. See the [Knative Repository Guidelines](../REPOSITORY-GUIDELINES.md) for
+more details on the requirements for the `knative-sandbox` org.
+
+## Criteria
+
+A Working Group Lead (either
+[technical](../ROLES.md#working-group-technical-lead) or
+[execution](../ROLES.md#working-group-execution-lead)) may request a new repo in
+`knative-sandbox` by filing an issue in the
+[knative/community](https://github.com/knative/community/issues/new?template=new-repo.md)
+repo. Once filed, the TOC should handle these promptly, though it should also be
+considered fine to ping members or the group on Slack if it hasn't been acted on
+in a few days. Generally, the request will be granted, though the TOC may have
+additional questions or suggest an alternate mechanism in some cases.
+
+Some of the following steps may require permissions that are only available to
+the TOC or Steering Committee, though others are largely self-service or require
+other WGs to review and approve impacting changes.
+
+### Technical requirements
+
+- Any contributed code should be contributed by the original authors or
+  copyright holders under an Apache 2.0 license. See also
+  [this section of the repository guidelines](../REPOSITORY-GUIDELINES.md#creation).
+
+- Names between `knative-sandbox` and the main `knative` repo should not
+  overlap. This simplifies promoting repos between the two orgs and setting up
+  `knative.dev` import paths for golang.
+
+- Prow automation for tests is encouraged but not required for
+  `knative-sandbox`, but the Google CLA bot and OWNERS files/tide merge should
+  be enforced.
+
+## Process (to be executed by TOC or Steering member)
+
+1. (Requires Org owner) Create the new repo in
+   https://github.com/knative-sandbox using the "New" button. Set the repo to
+   public and include an "Apache License 2.0" but no `.gitignore` or `README`.
+
+1. (Requires repo write/org owner) Create:
+
+   - `OWNERS` file listing TOC and WG members as approvers, and WG members as
+     reviewers
+
+   - `CODE-OF-CONDUCT.md` (that links to
+     https://github.com/knative/community/blob/master/CODE-OF-CONDUCT.md)
+
+   - `README.md` for the repo by cloning it and pushing directly to the repo.
+
+   At the end of this step, you should have 4 files: `LICENSE`, `OWNERS`,
+   `CODE-OF-CONDUCT.md`, and `README.md`
+
+1. Add entries for the repo to
+   [`../peribolos/knative-sandbox.yaml` in knative/community](https://github.com/knative/community/peribolos/knative-sandbox.yaml).
+   As part of this, grant one or more sponsoring WGs the "write" permission on
+   the repo ([sample PR](https://github.com/knative/community/pull/170))
+
+1. (For golang repos) Set up an alias under `knative.dev` to enable
+   `knative.dev/` golang imports by adding a file for the repo to
+   https://github.com/knative/website/tree/master/static/golang and updating the
+   [`_redirects`](https://github.com/knative/website/blob/master/static/_redirects)
+   file.
+
+1. Set up
+   [test-infra using the automation](https://github.com/knative/test-infra/blob/master/guides/prow_setup.md#setting-up-prow-for-a-new-repo-reviewers-assignment-and-auto-merge),
+   which probably involves updating `config/prod/prow/config_knative.yaml` and
+   then running `./hack/generate-configs.sh`
+
+1. Ensure that Prow is working correctly by creating a PR against the repo. One
+   good way to do this is to
+   [add a `test/presubmit-tests.sh`](https://github.com/knative-sandbox/discovery/pull/1)
+   via either the web UI or using a fork.
+
+1. Once at least one PR has been created, you'll be able to select the branch
+   protection checks which are required in the "Settings" > "Branches" branch
+   protection rule:
+
+   - Under "Branches" add a branch protection rule for `master`:
+     - Require status checks to pass (except `...-go-coverage` checks)
+     - Include administrators

peribolos/knative-sandbox.yaml

@@ -218,6 +218,8 @@ orgs:
     - zouyee
     - zrob
     repos:
+      # NOTE: If you are adding a repo here, you may also want to grant repo
+      # permissions for one or more teams, in the next section.
       build-spike:
         allow_merge_commit: false
         allow_rebase_merge: false

peribolos/knative.yaml

@@ -491,6 +491,8 @@ orgs:
     - zrss
     - zsxking
     repos:
+      # NOTE: If you are adding a repo here, you may also want to grant repo
+      # permissions for one or more teams, in the next section.
       build:
         allow_merge_commit: false
         allow_rebase_merge: false