Add post v1.0 PR merge details.

docs/devel/development.md

@@ -98,6 +98,7 @@ git push -f origin myfeature
 
 1. Visit http://github.com/$YOUR_GITHUB_USERNAME/kubernetes
 2. Click the "Compare and pull request" button next to your "myfeature" branch.
+3. Check out the pull request [process](pull-requests.md) for more details
 
 ### When to retain commits and when to squash
 

docs/devel/pull-requests.md

@@ -47,18 +47,19 @@ We want to limit the total number of PRs in flight to:
 * Remove old PRs that would be difficult to rebase as the underlying code has changed over time
 * Encourage code velocity
 
-RC to v1.0 Pull Requests
-------------------------
+Life of a Pull Request
+----------------------
 
-Between the first RC build (~6/22) and v1.0, we will adopt a higher bar for PR merges.  For v1.0 to be a stable release, we need to ensure that any fixes going in are very well tested and have a low risk of breaking anything.  Refactors and complex changes will be rejected in favor of more strategic and smaller workarounds.
+Unless in the last few weeks of a milestone when we need to reduce churn and stabilize, we aim to be always accepting pull requests.
 
-These PRs require:
-* A risk assessment by the code author in the PR.  This should outline which parts of the code are being touched, the risk of regression, and complexity of the code.
-* Two LGTMs from experienced reviewers.
+Either the [on call](https://github.com/GoogleCloudPlatform/kubernetes/wiki/Kubernetes-on-call-rotation) manually or the [submit queue](../../contrib/submit-queue/) automatically will manage merging PRs.
 
-Once those requirements are met, they will be labeled [ok-to-merge](https://github.com/GoogleCloudPlatform/kubernetes/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+label%3Aok-to-merge) and can be merged.
+There are several requirements for the submit queue to work:
+* Author must have signed CLA ("cla: yes" label added to PR)
+* No changes can be made since last lgtm label was applied
+* k8s-bot must have reported the GCE E2E build and test steps passed (Travis, Shippable and Jenkins build)
 
-These restrictions will be relaxed after v1.0 is released.
+Additionally, for infrequent or new contributors, we require the on call to apply the "ok-to-merge" label manually.  This is gated by the [whitelist](../../contrib/submit-queue/whitelist.txt).
 
 
 <!-- BEGIN MUNGE: GENERATED_ANALYTICS -->