1# Pull Requests 2 3There are two fundamental components of the Pull Request process: one concrete 4and technical, and one more process oriented. The concrete and technical 5component involves the specific details of setting up your local environment 6so that you can make the actual changes. This is where we will start. 7 8* [Dependencies](#dependencies) 9* [Setting up your local environment](#setting-up-your-local-environment) 10 * [Step 1: Fork](#step-1-fork) 11 * [Step 2: Branch](#step-2-branch) 12* [The Process of Making Changes](#the-process-of-making-changes) 13 * [Step 3: Code](#step-3-code) 14 * [Step 4: Commit](#step-4-commit) 15 * [Commit message guidelines](#commit-message-guidelines) 16 * [Step 5: Rebase](#step-5-rebase) 17 * [Step 6: Test](#step-6-test) 18 * [Test Coverage](#test-coverage) 19 * [Step 7: Push](#step-7-push) 20 * [Step 8: Opening the Pull Request](#step-8-opening-the-pull-request) 21 * [Step 9: Discuss and Update](#step-9-discuss-and-update) 22 * [Approval and Request Changes Workflow](#approval-and-request-changes-workflow) 23 * [Step 10: Landing](#step-10-landing) 24* [Reviewing Pull Requests](#reviewing-pull-requests) 25 * [Review a bit at a time](#review-a-bit-at-a-time) 26 * [Be aware of the person behind the code](#be-aware-of-the-person-behind-the-code) 27 * [Respect the minimum wait time for comments](#respect-the-minimum-wait-time-for-comments) 28 * [Abandoned or Stalled Pull Requests](#abandoned-or-stalled-pull-requests) 29 * [Approving a change](#approving-a-change) 30 * [Accept that there are different opinions about what belongs in Node.js](#accept-that-there-are-different-opinions-about-what-belongs-in-nodejs) 31 * [Performance is not everything](#performance-is-not-everything) 32 * [Continuous Integration Testing](#continuous-integration-testing) 33* [Notes](#notes) 34 * [Commit Squashing](#commit-squashing) 35 * [Getting Approvals for your Pull Request](#getting-approvals-for-your-pull-request) 36 * [CI Testing](#ci-testing) 37 * [Waiting Until the Pull Request Gets Landed](#waiting-until-the-pull-request-gets-landed) 38 * [Check Out the Collaborator Guide](#check-out-the-collaborator-guide) 39 40## Dependencies 41 42Node.js has several bundled dependencies in the *deps/* and the *tools/* 43directories that are not part of the project proper. Changes to files in those 44directories should be sent to their respective projects. Do not send a patch to 45Node.js. We cannot accept such patches. 46 47In case of doubt, open an issue in the 48[issue tracker](https://github.com/nodejs/node/issues/) or contact one of the 49[project Collaborators](https://github.com/nodejs/node/#current-project-team-members). 50Node.js has two IRC channels: 51[#Node.js](https://webchat.freenode.net/?channels=node.js) for general help and 52questions, and 53[#Node-dev](https://webchat.freenode.net/?channels=node-dev) for development of 54Node.js core specifically. 55 56## Setting up your local environment 57 58To get started, you will need to have `git` installed locally. Depending on 59your operating system, there are also a number of other dependencies required. 60These are detailed in the [Building guide][]. 61 62Once you have `git` and are sure you have all of the necessary dependencies, 63it's time to create a fork. 64 65### Step 1: Fork 66 67Fork the project [on GitHub](https://github.com/nodejs/node) and clone your fork 68locally. 69 70```text 71$ git clone git@github.com:username/node.git 72$ cd node 73$ git remote add upstream https://github.com/nodejs/node.git 74$ git fetch upstream 75``` 76 77It is recommended to configure `git` so that it knows who you are: 78 79```text 80$ git config user.name "J. Random User" 81$ git config user.email "j.random.user@example.com" 82``` 83 84You can use any name/email address you prefer here. We only use the 85metadata generated by `git` using this configuration for properly attributing 86your changes to you in the `AUTHORS` file and the changelog. 87 88If you would like for the Github UI to link the commit to your account 89and award you the `Contributor` label after the changes have been merged, 90make sure this local email is also added to your 91[GitHub email list](https://github.com/settings/emails). 92 93### Step 2: Branch 94 95As a best practice to keep your development environment as organized as 96possible, create local branches to work within. These should also be created 97directly off of the `master` branch. 98 99```text 100$ git checkout -b my-branch -t upstream/master 101``` 102 103## The Process of Making Changes 104 105### Step 3: Code 106 107The vast majority of Pull Requests opened against the `nodejs/node` 108repository includes changes to one or more of the following: 109 - the C/C++ code contained in the `src` directory 110 - the JavaScript code contained in the `lib` directory 111 - the documentation in `doc/api` 112 - tests within the `test` directory. 113 114If you are modifying code, please be sure to run `make lint` from time to 115time to ensure that the changes follow the Node.js code style guide. 116 117Any documentation you write (including code comments and API documentation) 118should follow the [Style Guide](../../STYLE_GUIDE.md). Code samples included 119in the API docs will also be checked when running `make lint` (or 120`vcbuild.bat lint` on Windows). 121 122For contributing C++ code, you may want to look at the 123[C++ Style Guide](../../../CPP_STYLE_GUIDE.md). 124 125### Step 4: Commit 126 127It is a recommended best practice to keep your changes as logically grouped 128as possible within individual commits. There is no limit to the number of 129commits any single Pull Request may have, and many contributors find it easier 130to review changes that are split across multiple commits. 131 132```text 133$ git add my/changed/files 134$ git commit 135``` 136 137Note that multiple commits often get squashed when they are landed (see the 138notes about [commit squashing](#commit-squashing)). 139 140#### Commit message guidelines 141 142A good commit message should describe what changed and why. 143 1441. The first line should: 145 - contain a short description of the change (preferably 50 characters or 146 less, and no more than 72 characters) 147 - be entirely in lowercase with the exception of proper nouns, acronyms, and 148 the words that refer to code, like function/variable names 149 - be prefixed with the name of the changed subsystem and start with an 150 imperative verb. Check the output of `git log --oneline files/you/changed` to 151 find out what subsystems your changes touch. 152 153 Examples: 154 - `net: add localAddress and localPort to Socket` 155 - `src: fix typos in async_wrap.h` 156 157 1582. Keep the second line blank. 1593. Wrap all other lines at 72 columns (except for long URLs). 160 1614. If your patch fixes an open issue, you can add a reference to it at the end 162of the log. Use the `Fixes:` prefix and the full issue URL. For other references 163use `Refs:`. 164 165 Examples: 166 - `Fixes: https://github.com/nodejs/node/issues/1337` 167 - `Refs: http://eslint.org/docs/rules/space-in-parens.html` 168 - `Refs: https://github.com/nodejs/node/pull/3615` 169 1705. If your commit introduces a breaking change (`semver-major`), it should 171contain an explanation about the reason of the breaking change, which 172situation would trigger the breaking change and what is the exact change. 173 174Sample complete commit message: 175 176```txt 177subsystem: explain the commit in one line 178 179Body of commit message is a few lines of text, explaining things 180in more detail, possibly giving some background about the issue 181being fixed, etc. 182 183The body of the commit message can be several paragraphs, and 184please do proper word-wrap and keep columns shorter than about 18572 characters or so. That way, `git log` will show things 186nicely even when it is indented. 187 188Fixes: https://github.com/nodejs/node/issues/1337 189Refs: http://eslint.org/docs/rules/space-in-parens.html 190``` 191 192If you are new to contributing to Node.js, please try to do your best at 193conforming to these guidelines, but do not worry if you get something wrong. 194One of the existing contributors will help get things situated and the 195contributor landing the Pull Request will ensure that everything follows 196the project guidelines. 197 198See [core-validate-commit](https://github.com/nodejs/core-validate-commit) - 199A utility that ensures commits follow the commit formatting guidelines. 200 201### Step 5: Rebase 202 203As a best practice, once you have committed your changes, it is a good idea 204to use `git rebase` (not `git merge`) to synchronize your work with the main 205repository. 206 207```text 208$ git fetch upstream 209$ git rebase upstream/master 210``` 211 212This ensures that your working branch has the latest changes from `nodejs/node` 213master. 214 215### Step 6: Test 216 217Bug fixes and features should always come with tests. A 218[guide for writing tests in Node.js][] has been 219provided to make the process easier. Looking at other tests to see how they 220should be structured can also help. 221 222The `test` directory within the `nodejs/node` repository is complex and it is 223often not clear where a new test file should go. When in doubt, add new tests 224to the `test/parallel/` directory and the right location will be sorted out 225later. 226 227Before submitting your changes in a Pull Request, always run the full Node.js 228test suite. To run the tests (including code linting) on Unix / macOS: 229 230```text 231$ ./configure && make -j4 test 232``` 233 234And on Windows: 235 236```text 237> vcbuild test 238``` 239 240(See the [Building guide][] for more details.) 241 242Make sure the linter does not report any issues and that all tests pass. Please 243do not submit patches that fail either check. 244 245If you want to run the linter without running tests, use 246`make lint`/`vcbuild lint`. It will run both JavaScript linting and 247C++ linting. 248 249If you are updating tests and just want to run a single test to check it: 250 251```text 252$ python tools/test.py -J --mode=release parallel/test-stream2-transform 253``` 254 255You can execute the entire suite of tests for a given subsystem 256by providing the name of a subsystem: 257 258```text 259$ python tools/test.py -J --mode=release child-process 260``` 261 262If you want to check the other options, please refer to the help by using 263the `--help` option 264 265```text 266$ python tools/test.py --help 267``` 268 269You can usually run tests directly with node: 270 271```text 272$ ./node ./test/parallel/test-stream2-transform.js 273``` 274 275Remember to recompile with `make -j4` in between test runs if you change code in 276the `lib` or `src` directories. 277 278#### Test Coverage 279 280It's good practice to ensure any code you add or change is covered by tests. 281You can do so by running the test suite with coverage enabled: 282 283```text 284$ ./configure --coverage && make coverage 285``` 286 287A detailed coverage report will be written to `coverage/index.html` for 288JavaScript coverage and to `coverage/cxxcoverage.html` for C++ coverage. 289 290_Note that generating a test coverage report can take several minutes._ 291 292To collect coverage for a subset of tests you can set the `CI_JS_SUITES` and 293`CI_NATIVE_SUITES` variables: 294 295```text 296$ CI_JS_SUITES=child-process CI_NATIVE_SUITES= make coverage 297``` 298 299The above command executes tests for the `child-process` subsystem and 300outputs the resulting coverage report. 301 302Running tests with coverage will create and modify several directories 303and files. To clean up afterwards, run: 304 305```text 306make coverage-clean 307./configure && make -j4. 308``` 309 310### Step 7: Push 311 312Once you are sure your commits are ready to go, with passing tests and linting, 313begin the process of opening a Pull Request by pushing your working branch to 314your fork on GitHub. 315 316```text 317$ git push origin my-branch 318``` 319 320### Step 8: Opening the Pull Request 321 322From within GitHub, opening a new Pull Request will present you with a template 323that should be filled out: 324 325```markdown 326<!-- 327Thank you for your Pull Request. Please provide a description above and review 328the requirements below. 329 330Bug fixes and new features should include tests and possibly benchmarks. 331 332Contributors guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md 333--> 334 335#### Checklist 336<!-- Remove items that do not apply. For completed items, change [ ] to [x]. --> 337 338- [ ] `make -j4 test` (UNIX), or `vcbuild test` (Windows) passes 339- [ ] tests and/or benchmarks are included 340- [ ] documentation is changed or added 341- [ ] commit message follows [commit guidelines](https://github.com/nodejs/node/blob/master/doc/guides/contributing/pull-requests.md#commit-message-guidelines) 342``` 343 344Please try to do your best at filling out the details, but feel free to skip 345parts if you're not sure what to put. 346 347Once opened, Pull Requests are usually reviewed within a few days. 348 349### Step 9: Discuss and update 350 351You will probably get feedback or requests for changes to your Pull Request. 352This is a big part of the submission process so don't be discouraged! Some 353contributors may sign off on the Pull Request right away, others may have 354more detailed comments or feedback. This is a necessary part of the process 355in order to evaluate whether the changes are correct and necessary. 356 357To make changes to an existing Pull Request, make the changes to your local 358branch, add a new commit with those changes, and push those to your fork. 359GitHub will automatically update the Pull Request. 360 361```text 362$ git add my/changed/files 363$ git commit 364$ git push origin my-branch 365``` 366 367It is also frequently necessary to synchronize your Pull Request with other 368changes that have landed in `master` by using `git rebase`: 369 370```text 371$ git fetch --all 372$ git rebase origin/master 373$ git push --force-with-lease origin my-branch 374``` 375 376**Important:** The `git push --force-with-lease` command is one of the few ways 377to delete history in `git`. Before you use it, make sure you understand the 378risks. If in doubt, you can always ask for guidance in the Pull Request or on 379[IRC in the #node-dev channel][]. 380 381If you happen to make a mistake in any of your commits, do not worry. You can 382amend the last commit (for example if you want to change the commit log). 383 384```text 385$ git add any/changed/files 386$ git commit --amend 387$ git push --force-with-lease origin my-branch 388``` 389 390There are a number of more advanced mechanisms for managing commits using 391`git rebase` that can be used, but are beyond the scope of this guide. 392 393Feel free to post a comment in the Pull Request to ping reviewers if you are 394awaiting an answer on something. If you encounter words or acronyms that 395seem unfamiliar, refer to this 396[glossary](https://sites.google.com/a/chromium.org/dev/glossary). 397 398#### Approval and Request Changes Workflow 399 400All Pull Requests require "sign off" in order to land. Whenever a contributor 401reviews a Pull Request they may find specific details that they would like to 402see changed or fixed. These may be as simple as fixing a typo, or may involve 403substantive changes to the code you have written. While such requests are 404intended to be helpful, they may come across as abrupt or unhelpful, especially 405requests to change things that do not include concrete suggestions on *how* to 406change them. 407 408Try not to be discouraged. If you feel that a particular review is unfair, 409say so, or contact one of the other contributors in the project and seek their 410input. Often such comments are the result of the reviewer having only taken a 411short amount of time to review and are not ill-intended. Such issues can often 412be resolved with a bit of patience. That said, reviewers should be expected to 413be helpful in their feedback, and feedback that is simply vague, dismissive and 414unhelpful is likely safe to ignore. 415 416### Step 10: Landing 417 418In order to land, a Pull Request needs to be reviewed and [approved][] by 419at least two Node.js Collaborators (one Collaborator approval is enough if the 420pull request has been open for more than 7 days) and pass a 421[CI (Continuous Integration) test run][]. After that, as long as there are no 422objections from other contributors, the Pull Request can be merged. If you find 423your Pull Request waiting longer than you expect, see the 424[notes about the waiting time](#waiting-until-the-pull-request-gets-landed). 425 426When a collaborator lands your Pull Request, they will post 427a comment to the Pull Request page mentioning the commit(s) it 428landed as. GitHub often shows the Pull Request as `Closed` at this 429point, but don't worry. If you look at the branch you raised your 430Pull Request against (probably `master`), you should see a commit with 431your name on it. Congratulations and thanks for your contribution! 432 433## Reviewing Pull Requests 434 435All Node.js contributors who choose to review and provide feedback on Pull 436Requests have a responsibility to both the project and the individual making the 437contribution. Reviews and feedback must be helpful, insightful, and geared 438towards improving the contribution as opposed to simply blocking it. If there 439are reasons why you feel the PR should not land, explain what those are. Do not 440expect to be able to block a Pull Request from advancing simply because you say 441"No" without giving an explanation. Be open to having your mind changed. Be open 442to working with the contributor to make the Pull Request better. 443 444Reviews that are dismissive or disrespectful of the contributor or any other 445reviewers are strictly counter to the [Code of Conduct][]. 446 447When reviewing a Pull Request, the primary goals are for the codebase to improve 448and for the person submitting the request to succeed. Even if a Pull Request 449does not land, the submitters should come away from the experience feeling like 450their effort was not wasted or unappreciated. Every Pull Request from a new 451contributor is an opportunity to grow the community. 452 453### Review a bit at a time. 454 455Do not overwhelm new contributors. 456 457It is tempting to micro-optimize and make everything about relative performance, 458perfect grammar, or exact style matches. Do not succumb to that temptation. 459 460Focus first on the most significant aspects of the change: 461 4621. Does this change make sense for Node.js? 4632. Does this change make Node.js better, even if only incrementally? 4643. Are there clear bugs or larger scale issues that need attending to? 4654. Is the commit message readable and correct? If it contains a breaking change 466 is it clear enough? 467 468When changes are necessary, *request* them, do not *demand* them, and do not 469assume that the submitter already knows how to add a test or run a benchmark. 470 471Specific performance optimization techniques, coding styles and conventions 472change over time. The first impression you give to a new contributor never does. 473 474Nits (requests for small changes that are not essential) are fine, but try to 475avoid stalling the Pull Request. Most nits can typically be fixed by the 476Node.js Collaborator landing the Pull Request but they can also be an 477opportunity for the contributor to learn a bit more about the project. 478 479It is always good to clearly indicate nits when you comment: e.g. 480`Nit: change foo() to bar(). But this is not blocking.` 481 482If your comments were addressed but were not folded automatically after new 483commits or if they proved to be mistaken, please, [hide them][hiding-a-comment] 484with the appropriate reason to keep the conversation flow concise and relevant. 485 486### Be aware of the person behind the code 487 488Be aware that *how* you communicate requests and reviews in your feedback can 489have a significant impact on the success of the Pull Request. Yes, we may land 490a particular change that makes Node.js better, but the individual might just 491not want to have anything to do with Node.js ever again. The goal is not just 492having good code. 493 494### Respect the minimum wait time for comments 495 496There is a minimum waiting time which we try to respect for non-trivial 497changes, so that people who may have important input in such a distributed 498project are able to respond. 499 500For non-trivial changes, Pull Requests must be left open for at least 48 hours. 501In most cases, when the PR is relatively small and focused on a narrow set of 502changes, that will provide more than enough time to adequately review. Sometimes 503changes take far longer to review, or need more specialized review from subject 504matter experts. When in doubt, do not rush. 505 506Trivial changes, typically limited to small formatting changes or fixes to 507documentation, may be landed within the minimum 48 hour window. 508 509### Abandoned or Stalled Pull Requests 510 511If a Pull Request appears to be abandoned or stalled, it is polite to first 512check with the contributor to see if they intend to continue the work before 513checking if they would mind if you took it over (especially if it just has 514nits left). When doing so, it is courteous to give the original contributor 515credit for the work they started (either by preserving their name and email 516address in the commit log, or by using an `Author: ` meta-data tag in the 517commit. 518 519### Approving a change 520 521Any Node.js core Collaborator (any GitHub user with commit rights in the 522`nodejs/node` repository) is authorized to approve any other contributor's 523work. Collaborators are not permitted to approve their own Pull Requests. 524 525Collaborators indicate that they have reviewed and approve of the changes in 526a Pull Request either by using GitHub's Approval Workflow, which is preferred, 527or by leaving an `LGTM` ("Looks Good To Me") comment. 528 529When explicitly using the "Changes requested" component of the GitHub Approval 530Workflow, show empathy. That is, do not be rude or abrupt with your feedback 531and offer concrete suggestions for improvement, if possible. If you're not 532sure *how* a particular change can be improved, say so. 533 534Most importantly, after leaving such requests, it is courteous to make yourself 535available later to check whether your comments have been addressed. 536 537If you see that requested changes have been made, you can clear another 538collaborator's `Changes requested` review. 539 540Change requests that are vague, dismissive, or unconstructive may also be 541dismissed if requests for greater clarification go unanswered within a 542reasonable period of time. 543 544If you do not believe that the Pull Request should land at all, use 545`Changes requested` to indicate that you are considering some of your comments 546to block the PR from landing. When doing so, explain *why* you believe the 547Pull Request should not land along with an explanation of what may be an 548acceptable alternative course, if any. 549 550### Accept that there are different opinions about what belongs in Node.js 551 552Opinions on this vary, even among the members of the Technical Steering 553Committee. 554 555One general rule of thumb is that if Node.js itself needs it (due to historic 556or functional reasons), then it belongs in Node.js. For instance, `url` 557parsing is in Node.js because of HTTP protocol support. 558 559Also, functionality that either cannot be implemented outside of core in any 560reasonable way, or only with significant pain. 561 562It is not uncommon for contributors to suggest new features they feel would 563make Node.js better. These may or may not make sense to add, but as with all 564changes, be courteous in how you communicate your stance on these. Comments 565that make the contributor feel like they should have "known better" or 566ridiculed for even trying run counter to the [Code of Conduct][]. 567 568### Performance is not everything 569 570Node.js has always optimized for speed of execution. If a particular change 571can be shown to make some part of Node.js faster, it's quite likely to be 572accepted. Claims that a particular Pull Request will make things faster will 573almost always be met by requests for performance [benchmark results][] that 574demonstrate the improvement. 575 576That said, performance is not the only factor to consider. Node.js also 577optimizes in favor of not breaking existing code in the ecosystem, and not 578changing working functional code just for the sake of changing. 579 580If a particular Pull Request introduces a performance or functional 581regression, rather than simply rejecting the Pull Request, take the time to 582work *with* the contributor on improving the change. Offer feedback and 583advice on what would make the Pull Request acceptable, and do not assume that 584the contributor should already know how to do that. Be explicit in your 585feedback. 586 587### Continuous Integration Testing 588 589All Pull Requests that contain changes to code must be run through 590continuous integration (CI) testing at [https://ci.nodejs.org/][]. 591 592Only Node.js core Collaborators with commit rights to the `nodejs/node` 593repository may start a CI testing run. The specific details of how to do 594this are included in the new Collaborator [Onboarding guide][]. 595 596Ideally, the code change will pass ("be green") on all platform configurations 597supported by Node.js (there are over 30 platform configurations currently). 598This means that all tests pass and there are no linting errors. In reality, 599however, it is not uncommon for the CI infrastructure itself to fail on 600specific platforms or for so-called "flaky" tests to fail ("be red"). It is 601vital to visually inspect the results of all failed ("red") tests to determine 602whether the failure was caused by the changes in the Pull Request. 603 604## Notes 605 606### Commit Squashing 607 608In most cases, do not squash commits that you add to your Pull Request during 609the review process. When the commits in your Pull Request land, they may be 610squashed into one commit per logical change. Metadata will be added to the 611commit message (including links to the Pull Request, links to relevant issues, 612and the names of the reviewers). The commit history of your Pull Request, 613however, will stay intact on the Pull Request page. 614 615For the size of "one logical change", 616[0b5191f](https://github.com/nodejs/node/commit/0b5191f15d0f311c804d542b67e2e922d98834f8) 617can be a good example. It touches the implementation, the documentation, 618and the tests, but is still one logical change. All tests should always pass 619when each individual commit lands on the master branch. 620 621### Getting Approvals for Your Pull Request 622 623A Pull Request is approved either by saying LGTM, which stands for 624"Looks Good To Me", or by using GitHub's Approve button. 625GitHub's Pull Request review feature can be used during the process. 626For more information, check out 627[the video tutorial](https://www.youtube.com/watch?v=HW0RPaJqm4g) 628or [the official documentation](https://help.github.com/articles/reviewing-changes-in-pull-requests/). 629 630After you push new changes to your branch, you need to get 631approval for these new changes again, even if GitHub shows "Approved" 632because the reviewers have hit the buttons before. 633 634### CI Testing 635 636Every Pull Request needs to be tested 637to make sure that it works on the platforms that Node.js 638supports. This is done by running the code through the CI system. 639 640Only a Collaborator can start a CI run. Usually one of them will do it 641for you as approvals for the Pull Request come in. 642If not, you can ask a Collaborator to start a CI run. 643 644### Waiting Until the Pull Request Gets Landed 645 646A Pull Request needs to stay open for at least 48 hours from when it is 647submitted, even after it gets approved and passes the CI. This is to make sure 648that everyone has a chance to weigh in. If the changes are trivial, 649collaborators may decide it doesn't need to wait. A Pull Request may well take 650longer to be merged in. All these precautions are important because Node.js is 651widely used, so don't be discouraged! 652 653### Check Out the Collaborator Guide 654 655If you want to know more about the code review and the landing process, see the 656[Collaborator Guide][]. 657 658[approved]: #getting-approvals-for-your-pull-request 659[benchmark results]: ../writing-and-running-benchmarks.md 660[Building guide]: ../../../BUILDING.md 661[CI (Continuous Integration) test run]: #ci-testing 662[Code of Conduct]: https://github.com/nodejs/admin/blob/master/CODE_OF_CONDUCT.md 663[Collaborator Guide]: ../../../COLLABORATOR_GUIDE.md 664[guide for writing tests in Node.js]: ../writing-tests.md 665[https://ci.nodejs.org/]: https://ci.nodejs.org/ 666[IRC in the #node-dev channel]: https://webchat.freenode.net?channels=node-dev&uio=d4 667[Onboarding guide]: ../../onboarding.md 668[hiding-a-comment]: https://help.github.com/articles/managing-disruptive-comments/#hiding-a-comment 669