* There is [a bot](https://github.com/nodejs-github-bot/github-bot) that applies subsystem labels (for example, `doc`, `test`, `assert`, or `buffer`) so that we know what parts of the code base the pull request modifies. It is not perfect, of course. Feel free to apply relevant labels and remove irrelevant labels from pull requests and issues.
* There is [a bot](https://github.com/nodejs-github-bot/github-bot) that applies subsystem labels (for example, `doc`, `test`, `assert`, or `buffer`) so that we know what parts of the code base the pull request modifies. It is not perfect, of course. Feel free to apply relevant labels and remove irrelevant labels from pull requests and issues.
@ -69,9 +74,11 @@ onboarding session.
* When adding a semver label, add a comment explaining why you're adding it. Do it right away so you don't forget!
* When adding a semver label, add a comment explaining why you're adding it. Do it right away so you don't forget!
* [**See "Who to CC in issues"**](./onboarding-extras.md#who-to-cc-in-issues)
* [**See "Who to CC in issues"**](./onboarding-extras.md#who-to-cc-in-issues)
* will also come more naturally over time
* This will come more naturally over time
* For many of the teams listed there, you can ask to be added if you are interested
* Some are WGs with some process around adding people, others are only there for notifications
* When a discussion gets heated, you can request that other collaborators keep an eye on it by opening an issue at the private [nodejs/moderation](https://github.com/nodejs/moderation) repository.
* When a discussion gets heated, you can request that other Collaborators keep an eye on it by opening an issue at the private [nodejs/moderation](https://github.com/nodejs/moderation) repository.
* This is a repository to which all members of the `nodejs` GitHub organization (not just Collaborators on Node.js core) have access. Its contents should not be shared externally.
* This is a repository to which all members of the `nodejs` GitHub organization (not just Collaborators on Node.js core) have access. Its contents should not be shared externally.
* You can find the full moderation policy [here](https://github.com/nodejs/TSC/blob/master/Moderation-Policy.md).
* You can find the full moderation policy [here](https://github.com/nodejs/TSC/blob/master/Moderation-Policy.md).
@ -100,18 +107,24 @@ onboarding session.
(especially if it just has nits left).
(especially if it just has nits left).
* Approving a change
* Approving a change
* Collaborators indicate that they have reviewed and approve of the
* Collaborators indicate that they have reviewed and approve of the
the changes in a pull request by commenting with `LGTM`, which stands
the changes in a pull request using Github’s approval interface
for "looks good to me".
* Some people like to comment `LGTM` (“Looks Good To Me”)
* You have the power to `LGTM` another collaborator's (including TSC/CTC
* You have the authority to approve any other collaborator’s work.
members) work.
* You cannot approve your own pull requests.
* You may not `LGTM` your own pull requests.
* When explicitly using `Changes requested`, show empathy – comments will
* You have the power to `LGTM` anyone else's pull requests.
usually be addressed even if you don’t use it.
* If you do, it is nice if you are available later to check whether your
* What belongs in node:
comments have been addressed
* opinions vary, but I find the following helpful:
* If you see that the requested changes have been made, you can clear another collaborator's
* if node itself needs it (due to historic reasons), then it belongs in node
`Changes requested` review.
* that is to say, url is there because of http, freelist is there because of http, et al
* Use `Changes requested` to indicate that you are considering some of
* also, things that cannot be done outside of core, or only with significant pain (example: async-wrap)
your comments to block the PR from landing.
* What belongs in Node.js:
* Opinions vary – it’s good to have a broad collaborator base for that reason!
* If Node.js itself needs it (due to historic reasons), then it belongs in Node.js
* That is to say, url is there because of http, freelist is there because of http, etc.
* Things that cannot be done outside of core, or only with significant pain (for example `async_hooks`)