chore(docs): explain the process for merging changes to master

Closes angular#3566

Author: alexeagle

Diff for: COMMITTER.md

@@ -0,0 +1,31 @@
+# Pushing changes into the Angular 2 tree
+
+Please see [Using git with Angular repositories](https://docs.google.com/document/d/1h8nijFSaa1jG_UE8v4WP7glh5qOUXnYtAtJh_gwOQHI/edit)
+for details about how we maintain a linear commit history, and the rules for committing.
+
+As a contributor, just read the instructions in [CONTRIBUTING.md](CONTRIBUTING.md) and send a pull request.
+Someone with committer access will do the rest.
+
+## The `PR: merge` label and `presubmit-*` branches
+
+We have automated the process for merging pull requests into master. Our goal is to minimize the disruption for
+Angular committers and also prevent breakages on master.
+
+When a PR is ready to merge, a project member in the CoreTeamMember list (see below) can add the special label,
+`PR: merge`.
+A robot running as [mary-poppins](https://github.com/mary-poppins)
+is notified that the label was added by an authorized person,
+and will create a new branch in the angular project, using the convention `presubmit-{username}-pr-{number}`.
+
+(Note: if the automation fails, committers can instead push the commits to a branch following this naming scheme.)
+
+When a Travis build succeeds for a presubmit branch named following the convention,
+Travis will re-base the commits, merge to master, and close the PR automatically.
+
+Finally, after merge `mary-poppins` removes the presubmit branch.
+
+## Administration
+
+The list of users who can trigger a merge by adding the label is stored in our appengine app datastore.
+Edit the contents of the [CoreTeamMember Table](
+https://console.developers.google.com/project/angular2-automation/datastore/query?queryType=KindQuery&namespace=&kind=CoreTeamMember)

Diff for: TRIAGE_AND_LABELS.md

@@ -44,13 +44,13 @@ closing or reviewing PRs is a top priority ahead of other ongoing work.
 
 Every triaged PR must have a `pr_action` label assigned to it and an assignee:
 
+* `pr_action: review` -- work is complete and comment is needed from the assignee.
 * `pr_action: cleanup` -- more work is needed from the current assignee. 
 * `pr_action: discuss` -- discussion is needed, to be led by the current assignee.
-* `pr_action: merge` -- OK to merge this as soon as tests are green, `pr_state: LGTM`, and `CLA: 
-yes` are true. assignee (or anyone else) can merge.
-* `pr_action: review` -- work is complete and comment is needed from the assignee.
+* `pr_action: merge` -- the PR should be merged. Add this to a PR when you would like to 
+  trigger automatic merging following a successful build. This is described in [COMMITTER.md](COMMITTER.md).
 
-In addition, PRs can have the following states: 
+In addition, PRs can have the following states:
 
 * `pr_state: LGTM` -- PR may have outstanding changes but does not require further review.
 * `pr_state: WIP` -- PR is experimental or rapidly changing. Not ready for review or triage.