|
4 | 4 | * [Setting up your local environment](#setting-up-your-local-environment) |
5 | 5 | * [Step 1: Fork](#step-1-fork) |
6 | 6 | * [Step 2: Branch](#step-2-branch) |
7 | | -* [The Process of Making Changes](#the-process-of-making-changes) |
| 7 | +* [The process of making changes](#the-process-of-making-changes) |
8 | 8 | * [Step 3: Code](#step-3-code) |
9 | 9 | * [Step 4: Commit](#step-4-commit) |
10 | 10 | * [Commit message guidelines](#commit-message-guidelines) |
11 | 11 | * [Step 5: Rebase](#step-5-rebase) |
12 | 12 | * [Step 6: Test](#step-6-test) |
13 | 13 | * [Step 7: Push](#step-7-push) |
14 | | - * [Step 8: Opening the Pull Request](#step-8-opening-the-pull-request) |
15 | | - * [Step 9: Discuss and Update](#step-9-discuss-and-update) |
16 | | - * [Approval and Request Changes Workflow](#approval-and-request-changes-workflow) |
| 14 | + * [Step 8: Opening the pull request](#step-8-opening-the-pull-request) |
| 15 | + * [Step 9: Discuss and update](#step-9-discuss-and-update) |
| 16 | + * [Approval and request changes workflow](#approval-and-request-changes-workflow) |
17 | 17 | * [Step 10: Landing](#step-10-landing) |
18 | | -* [Reviewing Pull Requests](#reviewing-pull-requests) |
| 18 | +* [Reviewing pull requests](#reviewing-pull-requests) |
19 | 19 | * [Review a bit at a time](#review-a-bit-at-a-time) |
20 | 20 | * [Be aware of the person behind the code](#be-aware-of-the-person-behind-the-code) |
21 | 21 | * [Respect the minimum wait time for comments](#respect-the-minimum-wait-time-for-comments) |
22 | | - * [Abandoned or Stalled Pull Requests](#abandoned-or-stalled-pull-requests) |
| 22 | + * [Abandoned or stalled pull requests](#abandoned-or-stalled-pull-requests) |
23 | 23 | * [Approving a change](#approving-a-change) |
24 | 24 | * [Accept that there are different opinions about what belongs in Node.js](#accept-that-there-are-different-opinions-about-what-belongs-in-nodejs) |
25 | 25 | * [Performance is not everything](#performance-is-not-everything) |
26 | | - * [Continuous Integration Testing](#continuous-integration-testing) |
| 26 | + * [Continuous integration testing](#continuous-integration-testing) |
27 | 27 | * [Notes](#notes) |
28 | | - * [Commit Squashing](#commit-squashing) |
29 | | - * [Getting Approvals for your Pull Request](#getting-approvals-for-your-pull-request) |
30 | | - * [CI Testing](#ci-testing) |
31 | | - * [Waiting Until the Pull Request Gets Landed](#waiting-until-the-pull-request-gets-landed) |
32 | | - * [Check Out the Collaborator Guide](#check-out-the-collaborator-guide) |
33 | | - * [Appendix: Subsystems](#appendix-subsystems) |
| 28 | + * [Commit squashing](#commit-squashing) |
| 29 | + * [Getting approvals for your pull request](#getting-approvals-for-your-pull-request) |
| 30 | + * [CI testing](#ci-testing) |
| 31 | + * [Waiting until the pull request gets landed](#waiting-until-the-pull-request-gets-landed) |
| 32 | + * [Check out the collaborator guide](#check-out-the-collaborator-guide) |
| 33 | + * [Appendix: subsystems](#appendix-subsystems) |
34 | 34 |
|
35 | 35 | ## Dependencies |
36 | 36 |
|
@@ -107,7 +107,7 @@ directly off of the `master` branch. |
107 | 107 | $ git checkout -b my-branch -t upstream/master |
108 | 108 | ``` |
109 | 109 |
|
110 | | -## The Process of Making Changes |
| 110 | +## The process of making changes |
111 | 111 |
|
112 | 112 | ### Step 3: Code |
113 | 113 |
|
@@ -261,7 +261,7 @@ your fork on GitHub. |
261 | 261 | $ git push origin my-branch |
262 | 262 | ``` |
263 | 263 |
|
264 | | -### Step 8: Opening the Pull Request |
| 264 | +### Step 8: Opening the pull request |
265 | 265 |
|
266 | 266 | From within GitHub, opening a new Pull Request will present you with a |
267 | 267 | [pull request template][]. Please try to do your best at filling out the |
@@ -318,7 +318,7 @@ awaiting an answer on something. If you encounter words or acronyms that |
318 | 318 | seem unfamiliar, refer to this |
319 | 319 | [glossary](https://sites.google.com/a/chromium.org/dev/glossary). |
320 | 320 |
|
321 | | -#### Approval and Request Changes Workflow |
| 321 | +#### Approval and request changes workflow |
322 | 322 |
|
323 | 323 | All Pull Requests require "sign off" in order to land. Whenever a contributor |
324 | 324 | reviews a Pull Request they may find specific details that they would like to |
@@ -353,7 +353,7 @@ point, but don't worry. If you look at the branch you raised your |
353 | 353 | Pull Request against (probably `master`), you should see a commit with |
354 | 354 | your name on it. Congratulations and thanks for your contribution! |
355 | 355 |
|
356 | | -## Reviewing Pull Requests |
| 356 | +## Reviewing pull requests |
357 | 357 |
|
358 | 358 | All Node.js contributors who choose to review and provide feedback on Pull |
359 | 359 | Requests have a responsibility to both the project and the individual making the |
@@ -429,7 +429,7 @@ matter experts. When in doubt, do not rush. |
429 | 429 | Trivial changes, typically limited to small formatting changes or fixes to |
430 | 430 | documentation, may be landed within the minimum 48 hour window. |
431 | 431 |
|
432 | | -### Abandoned or Stalled Pull Requests |
| 432 | +### Abandoned or stalled pull requests |
433 | 433 |
|
434 | 434 | If a Pull Request appears to be abandoned or stalled, it is polite to first |
435 | 435 | check with the contributor to see if they intend to continue the work before |
@@ -507,7 +507,7 @@ advice on what would make the Pull Request acceptable, and do not assume that |
507 | 507 | the contributor should already know how to do that. Be explicit in your |
508 | 508 | feedback. |
509 | 509 |
|
510 | | -### Continuous Integration Testing |
| 510 | +### Continuous integration testing |
511 | 511 |
|
512 | 512 | All Pull Requests that contain changes to code must be run through |
513 | 513 | continuous integration (CI) testing at [https://ci.nodejs.org/][]. |
@@ -526,7 +526,7 @@ whether the failure was caused by the changes in the Pull Request. |
526 | 526 |
|
527 | 527 | ## Notes |
528 | 528 |
|
529 | | -### Commit Squashing |
| 529 | +### Commit squashing |
530 | 530 |
|
531 | 531 | In most cases, do not squash commits that you add to your Pull Request during |
532 | 532 | the review process. When the commits in your Pull Request land, they may be |
@@ -541,7 +541,7 @@ can be a good example. It touches the implementation, the documentation, |
541 | 541 | and the tests, but is still one logical change. All tests should always pass |
542 | 542 | when each individual commit lands on the master branch. |
543 | 543 |
|
544 | | -### Getting Approvals for Your Pull Request |
| 544 | +### Getting approvals for your pull request |
545 | 545 |
|
546 | 546 | A Pull Request is approved either by saying LGTM, which stands for |
547 | 547 | "Looks Good To Me", or by using GitHub's Approve button. |
@@ -554,7 +554,7 @@ After you push new changes to your branch, you need to get |
554 | 554 | approval for these new changes again, even if GitHub shows "Approved" |
555 | 555 | because the reviewers have hit the buttons before. |
556 | 556 |
|
557 | | -### CI Testing |
| 557 | +### CI testing |
558 | 558 |
|
559 | 559 | Every Pull Request needs to be tested |
560 | 560 | to make sure that it works on the platforms that Node.js |
@@ -564,7 +564,7 @@ Only a Collaborator can start a CI run. Usually one of them will do it |
564 | 564 | for you as approvals for the Pull Request come in. |
565 | 565 | If not, you can ask a Collaborator to start a CI run. |
566 | 566 |
|
567 | | -### Waiting Until the Pull Request Gets Landed |
| 567 | +### Waiting until the pull request gets landed |
568 | 568 |
|
569 | 569 | A Pull Request needs to stay open for at least 48 hours from when it is |
570 | 570 | submitted, even after it gets approved and passes the CI. This is to make sure |
@@ -573,12 +573,12 @@ collaborators may decide it doesn't need to wait. A Pull Request may well take |
573 | 573 | longer to be merged in. All these precautions are important because Node.js is |
574 | 574 | widely used, so don't be discouraged! |
575 | 575 |
|
576 | | -### Check Out the Collaborator Guide |
| 576 | +### Check out the collaborator guide |
577 | 577 |
|
578 | 578 | If you want to know more about the code review and the landing process, see the |
579 | 579 | [Collaborator Guide][]. |
580 | 580 |
|
581 | | -### Appendix: Subsystems |
| 581 | +### Appendix: subsystems |
582 | 582 |
|
583 | 583 | * `lib/*.js` (`assert`, `buffer`, etc.) |
584 | 584 | * `build` |
|