* The remaining elements on the form are typically unchanged with the exception of `POST_STATUS_TO_PR`. Check that if you want a CI status indicator to be automatically inserted into the PR.

* The [Collaborator Guide](https://github.com/nodejs/node/blob/master/COLLABORATOR_GUIDE.md#technical-howto) is a great resource.

* No one (including TSC or CTC members) pushes directly to master without review.

* An exception is made for release commits only.

* One `LGTM` is sufficient, except for semver-major changes.

* More than one is better.

* Breaking changes must be LGTM'ed by at least two CTC members.

* If one or more Collaborators object to a change, it should not land until

the objection is addressed. The options for such a situation include:

* Engaging those with objections to determine a viable path forward;

* Altering the pull request to address the objections;

* Escalating the discussion to the CTC using the `ctc-agenda` label. This should only be done after other options have been exhausted.

* Wait before merging non-trivial changes.

* 48 hours during the week and 72 hours on weekends.

* An example of a trivial change would be correcting the misspelling of a single word in a documentation file. This sort of change still needs to receive at least one `LGTM` but it does not need to wait 48 hours before landing.

* **Run the PR through CI before merging!**

* An exception can be made for documentation-only PRs as long as it does not include the `addons.md` documentation file. (Example code from that document is extracted and built as part of the tests!)

* What if something goes wrong?

* Ping a CTC member.

* `#node-dev` on freenode

* Force-pushing to fix things after is allowed for ~10 minutes. Avoid it if you can.

* Use `--force-with-lease` to minimize the chance of overwriting someone else's change.

* Post to `#node-dev` (IRC) if you force push.

* Please never use GitHub's green "Merge Pull Request" button.

* If you do, please force-push removing the merge.

Landing a PR

* if it all looks good, `curl -L 'url-of-pr.patch' | git am`

* If `git am` fails, see [the relevant section of the Onboarding Extras doc](./onboarding-extras.md#if-git-am-fails).

* `git rebase -i upstream/master`

* squash into logical commits if necessary

* `./configure && make -j8 test` (`-j8` builds node in parallel with 8 threads. adjust to the number of cores (or processor-level threads) your processor has (or slightly more) for best results.)

* `Reviewed-By: human <email>`

* Easiest to use `git log` then do a search

* (`/Name` + `enter` (+ `n` as much as you need to) in vim)

* Only include collaborators who have commented `LGTM`

* `PR-URL: <full-pr-url>`

* `git push upstream master`

* close the original PR with "Landed in `<commit hash>`".