v6.9.2 proposal

.eslintrc

@@ -2,6 +2,9 @@ env:
   node: true
   es6: true
 
+parserOptions:
+  ecmaVersion: 2016
+
 rules:
   # Possible Errors
   # http://eslint.org/docs/rules/#possible-errors
@@ -63,6 +66,12 @@ rules:
     object: assert,
     property: deepEqual,
     message: Please use assert.deepStrictEqual().
+  }, {
+    property: __defineGetter__,
+    message: __defineGetter__ is deprecated.
+  }, {
+    property: __defineSetter__,
+    message: __defineSetter__ is deprecated.
   }]
 
   # Stylistic Issues
@@ -112,7 +121,6 @@ rules:
   align-multiline-assignment: 2
   assert-fail-single-argument: 2
   new-with-error: [2, Error, RangeError, TypeError, SyntaxError, ReferenceError]
-  no-definegetter-definesetter: 2
 
 # Global scoped method and vars
 globals:

.github/ISSUE_TEMPLATE.md

@@ -1,5 +1,11 @@
 <!--
 Thank you for reporting an issue.
+
+This issue tracker is for bugs and issues found within Node.js core.
+If you require more general support please file an issue on our help
+repo. https://github.com/nodejs/help
+
+
 Please fill in as much of the template below as you're able.
 
 Version: output of `node -v`

.gitignore

@@ -88,7 +88,7 @@ deps/npm/node_modules/.bin/
 # test artifacts
 tools/faketime
 icu_config.gypi
-test.tap
+*.tap
 
 # Xcode workspaces and project folders
 *.xcodeproj

BUILDING.md

@@ -230,7 +230,7 @@ as `deps/icu` (You'll have: `deps/icu/source/...`)
 NOTE: Windows is not yet supported
 
 It is possible to build Node.js with
-[OpenSSL FIPS module](https://www.openssl.org/docs/fips/fipsnotes.html).
+[OpenSSL FIPS module](https://www.openssl.org/docs/fipsnotes.html).
 
 **Note**: building in this way does **not** allow you to claim that the
 runtime is FIPS 140-2 validated. Instead you can indicate that the runtime

CHANGELOG.md

@@ -18,15 +18,16 @@ release.
 
 <table>
 <tr>
-  <th><a href="doc/changelogs/CHANGELOG_V6.md">v6</a><sup>Current</sup</th>
+  <th title="LTS Until 2019-04"><a href="doc/changelogs/CHANGELOG_V6.md">v6</a><sup>LTS</sup</th>
   <th><a href="doc/changelogs/CHANGELOG_V5.md">v5</a></th>
   <th title="LTS Until 2018-04"><a href="doc/changelogs/CHANGELOG_V4.md">v4</a><sup>LTS</sup></th>
   <th title="LTS Until 2016-12-31"><a href="doc/changelogs/CHANGELOG_V012.md">v0.12</a><sup>LTS</sup></th>
   <th title="LTS Until 2016-10-31" colspan="3"><a href="doc/changelogs/CHANGELOG_V010.md">v0.10</a><sup>LTS</sup></th>
 </tr>
 <tr>
   <td valign="top">
-<b><a href="doc/changelogs/CHANGELOG_V6.md#6.9.1">6.9.1</a></b><br/>
+<b><a href="doc/changelogs/CHANGELOG_V6.md#6.9.2">6.9.2</a></b><br/>
+<a href="doc/changelogs/CHANGELOG_V6.md#6.9.1">6.9.1</a><br/>
 <a href="doc/changelogs/CHANGELOG_V6.md#6.9.0">6.9.0</a><br/>
 <a href="doc/changelogs/CHANGELOG_V6.md#6.8.1">6.8.1</a><br/>
 <a href="doc/changelogs/CHANGELOG_V6.md#6.8.0">6.8.0</a><br/>

COLLABORATOR_GUIDE.md

@@ -84,7 +84,7 @@ continuous integration tests on the
 ### Involving the CTC
 
 Collaborators may opt to elevate pull requests or issues to the CTC for
-discussion by assigning the ***ctc-agenda*** tag. This should be done
+discussion by assigning the `ctc-review` label. This should be done
 where a pull request:
 
 - has a significant impact on the codebase,
@@ -101,6 +101,8 @@ information regarding the change process:
 
 - A `Reviewed-By: Name <email>` line for yourself and any
   other Collaborators who have reviewed the change.
+  - Useful for @mentions / contact list if something goes wrong in the PR.
+  - Protects against the assumption that GitHub will be around forever.
 - A `PR-URL:` line that references the *full* GitHub URL of the original
   pull request being merged so it's easy to trace a commit back to the
   conversation that led up to that change.

CONTRIBUTING.md

@@ -89,6 +89,13 @@ $ git config --global user.name "J. Random User"
 $ git config --global user.email "[email protected]"
 ```
 
+Add and commit:
+
+```text
+$ git add my/changed/files
+$ git commit
+```
+
 Writing good commit logs is important. A commit log should describe what
 changed and why. Follow these guidelines when writing one:
 
@@ -194,10 +201,60 @@ $ git push origin my-branch
 Go to https://github.com/yourusername/node and select your branch.
 Click the 'Pull Request' button and fill out the form.
 
-Pull requests are usually reviewed within a few days. If there are comments
-to address, apply your changes in a separate commit and push that to your
-branch. Post a comment in the pull request afterwards; GitHub does
-not send out notifications when you add commits.
+Pull requests are usually reviewed within a few days.
+
+### Step 7: Discuss and update
+
+You will probably get feedback or requests for changes to your Pull Request.
+This is a big part of the submission process, so don't be disheartened!
+
+To make changes to an existing Pull Request, make the changes to your branch.
+When you push that branch to your fork, GitHub will automatically update the
+Pull Request.
+
+You can push more commits to your branch:
+
+```text
+$ git add my/changed/files
+$ git commit
+$ git push origin my-branch
+```
+
+Or you can rebase against master:
+
+```text
+$ git fetch --all
+$ git rebase origin/master
+$ git push --force-with-lease origin my-branch
+```
+
+Or you can amend the last commit (for example if you want to change the commit
+log).
+
+```text
+$ git add any/changed/files
+$ git commit --amend
+$ git push --force-with-lease origin my-branch
+```
+
+**Important:** The `git push --force-with-lease` command is one of the few ways
+to delete history in git. Before you use it, make sure you understand the risks.
+If in doubt, you can always ask for guidance in the Pull Request or on
+[IRC in the #node-dev channel](https://webchat.freenode.net?channels=node-dev&uio=d4).
+
+Feel free to post a comment in the Pull Request to ping reviewers if you are
+awaiting an answer on something.
+
+
+### Step 8: Landing
+
+Once your Pull Request has been reviewed and approved by at least one Node.js
+Collaborators (often by saying LGTM, or Looks Good To Me), and as long as
+there is consensus (no objections from a Collaborator), a
+Collaborator can merge the Pull Request . GitHub often shows the Pull Request as
+ `Closed` at this point, but don't worry. If you look at the branch you raised
+ your Pull Request against (probably `master`), you should see a commit with
+ your name on it. Congratulations and thanks for your contribution!
 
 <a id="developers-certificate-of-origin"></a>
 ## Developer's Certificate of Origin 1.1

GOVERNANCE.md

@@ -23,14 +23,11 @@ The [nodejs/node](https://github.com/nodejs/node) GitHub repository is
 maintained by the CTC and additional Collaborators who are added by the
 CTC on an ongoing basis.
 
-Individuals making significant and valuable contributions are made
-Collaborators and given commit-access to the project. These
-individuals are identified by the CTC and their addition as
-Collaborators is discussed during the weekly CTC meeting.
+Individuals identified by the CTC as making significant and valuable
+contributions are made Collaborators and given commit access to the project.
 
 _Note:_ If you make a significant contribution and are not considered
-for commit-access, log an issue or contact a CTC member directly and it
-will be brought up in the next CTC meeting.
+for commit access, log an issue or contact a CTC member directly.
 
 Modifications of the contents of the nodejs/node repository are made on
 a collaborative basis. Anybody with a GitHub account may propose a
@@ -39,16 +36,21 @@ Collaborators. All pull requests must be reviewed and accepted by a
 Collaborator with sufficient expertise who is able to take full
 responsibility for the change. In the case of pull requests proposed
 by an existing Collaborator, an additional Collaborator is required
-for sign-off. Consensus should be sought if additional Collaborators
-participate and there is disagreement around a particular
-modification. See [Consensus Seeking Process](#consensus-seeking-process) below
-for further detail on the consensus model used for governance.
+for sign-off.
 
-Collaborators may opt to elevate significant or controversial
-modifications, or modifications that have not found consensus to the
-CTC for discussion by assigning the ***ctc-agenda*** tag to a pull
-request or issue. The CTC should serve as the final arbiter where
-required.
+If one or more Collaborators oppose a proposed change, then the change can not
+be accepted unless:
+
+* Discussions and/or additional changes result in no Collaborators objecting to
+  the change. Previously-objecting Collaborators do not necessarily have to
+  sign-off on the change, but they should not be opposed to it.
+* The change is escalated to the CTC and the CTC votes to approve the change.
+  This should be used only after other options (especially discussion among
+  the disagreeing Collaborators) have been exhausted.
+
+Collaborators may opt to elevate significant or controversial modifications to
+the CTC by assigning the `ctc-review` label to a pull request or issue. The
+CTC should serve as the final arbiter where required.
 
 For the current list of Collaborators, see the project
 [README.md](./README.md#current-project-team-members).
@@ -103,7 +105,7 @@ members affiliated with the over-represented employer(s).
 Typical activities of a CTC member include:
 
 * attending the weekly meeting
-* commenting on the weekly CTC meeting issue and issues labeled `ctc-agenda`
+* commenting on the weekly CTC meeting issue and issues labeled `ctc-review`
 * participating in CTC email threads
 * volunteering for tasks that arise from CTC meetings and related discussions
 * other activities (beyond those typical of Collaborators) that facilitate the
@@ -115,7 +117,8 @@ Collaborator activities as well.
 ### CTC Meetings
 
 The CTC meets weekly in a voice conference call. The meeting is run by a
-designated moderator approved by the CTC. Each meeting is streamed on YouTube.
+designated meeting chair approved by the CTC. Each meeting is streamed on
+YouTube.
 
 Items are added to the CTC agenda which are considered contentious or
 are modifications of governance, contribution policy, CTC membership,
@@ -125,30 +128,46 @@ The intention of the agenda is not to approve or review all patches.
 That should happen continuously on GitHub and be handled by the larger
 group of Collaborators.
 
-Any community member or contributor can ask that something be added to
-the next meeting's agenda by logging a GitHub issue. Any Collaborator,
-CTC member or the moderator can add the item to the agenda by adding
-the ***ctc-agenda*** tag to the issue.
+Any community member or contributor can ask that something be reviewed
+by the CTC by logging a GitHub issue. Any Collaborator, CTC member, or the
+meeting chair can bring the issue to the CTC's attention by applying the
+`ctc-review` label. If consensus-seeking among CTC members fails for a
+particular issue, it may be added to the CTC meeting agenda by adding the
+`ctc-agenda` label.
 
-Prior to each CTC meeting, the moderator will share the agenda with
+Prior to each CTC meeting, the meeting chair will share the agenda with
 members of the CTC. CTC members can also add items to the agenda at the
-beginning of each meeting. The moderator and the CTC cannot veto or remove
+beginning of each meeting. The meeting chair and the CTC cannot veto or remove
 items.
 
 The CTC may invite persons or representatives from certain projects to
 participate in a non-voting capacity.
 
-The moderator is responsible for summarizing the discussion of each agenda item
-and sending it as a pull request after the meeting.
+The meeting chair is responsible for ensuring that minutes are taken and that a
+pull request with the minutes is submitted after the meeting.
+
+Due to the challenges of scheduling a global meeting with participants in
+several timezones, the CTC will seek to resolve as many agenda items as possible
+outside of meetings using
+[the CTC issue tracker](https://github.com/nodejs/CTC/issues). The process in
+the issue tracker is:
+
+* A CTC member opens an issue explaining the proposal/issue and @-mentions
+  @nodejs/ctc.
+* After 72 hours, if there are two or more `LGTM`s from other CTC members and no
+  explicit opposition from other CTC members, then the proposal is approved.
+* If there are any CTC members objecting, then a conversation ensues until
+  either the proposal is dropped or the objecting members are persuaded. If
+  there is an extended impasse, a motion for a vote may be made.
 
 ## Consensus Seeking Process
 
 The CTC follows a
 [Consensus Seeking](http://en.wikipedia.org/wiki/Consensus-seeking_decision-making)
 decision making model.
 
-When an agenda item has appeared to reach a consensus, the moderator will ask
-"Does anyone object?" as a final call for dissent from the consensus.
+When an agenda item has appeared to reach a consensus, the meeting chair will
+ask "Does anyone object?" as a final call for dissent from the consensus.
 
 If an agenda item cannot reach a consensus, a CTC member can call for either a
 closing vote or a vote to table the issue to the next meeting. All votes