* 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!
* [**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.
* 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).
* Approving a change
* Collaborators indicate that they have reviewed and approve of the
the changes in a pull request by commenting with `LGTM`, which stands
for "looks good to me".
* You have the power to `LGTM` another collaborator's (including TSC/CTC
members) work.
* You may not `LGTM` your own pull requests.
* You have the power to `LGTM` anyone else's pull requests.
* What belongs in node:
* opinions vary, but I find the following helpful:
* if node itself needs it (due to historic reasons), then it belongs in node
* that is to say, url is there because of http, freelist is there because of http, et al
* also, things that cannot be done outside of core, or only with significant pain (example: async-wrap)
the changes in a pull request using Github’s approval interface
* Some people like to comment `LGTM` (“Looks Good To Me”)
* You have the authority to approve any other collaborator’s work.
* You cannot approve your own pull requests.
* When explicitly using `Changes requested`, show empathy – comments will
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
comments have been addressed
* If you see that the requested changes have been made, you can clear another collaborator's
`Changes requested` review.
* Use `Changes requested` to indicate that you are considering some of
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`)