This document is an outline of the things we tell new Collaborators at their onboarding session.
node-core-utils
and set up the credentials for it.git:
git config --global --add apply.whitespace fix
nodejs/node
repository are only for release linesupstream
remote:git remote add upstream git://github.com/nodejs/node.git
upstream
:git checkout master
git remote update -p
OR git fetch --all
git merge --ff-only upstream/master
(or REMOTENAME/BRANCH
)Notifications:
#node-dev
on webchat.freenode.net is the best place to interact with the TSC / other Collaborators
master
Collaborators are the collective owners of the project
There are some higher-level goals and values
You are expected to follow and hold others accountable to the Code of Conduct.
You have (mostly) free rein; don't hesitate to close an issue if you are confident that it should be closed
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.semver-{minor,major}
:semver-major
labelsemver-*
label, add a comment explaining why you‘re adding it. Do it right away so you don’t forget!author-ready
label for PRs, if applicable.See Who to CC in the issue tracker.
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 repository.
nodejs
GitHub organization (not just Collaborators on Node.js core) have access. Its contents should not be shared externally.The primary goal is for the codebase to improve.
Secondary (but not far off) is for the person submitting code to succeed. A pull request from a new contributor is an opportunity to grow the community.
Review a bit at a time. Do not overwhelm new contributors.
Be aware: Your opinion carries a lot of weight!
Nits (requests for small changes that are not essential) are fine, but try to avoid stalling the pull request.
Nit: change foo() to bar().
Insofar as possible, issues should be identified by tools rather than human reviewers. If you are leaving comments about issues that could be identified by tools but are not, consider implementing the necessary tooling.
Minimum wait for comments time
Approving a change
LGTM
(“Looks Good To Me”)Changes requested
, show empathy – comments will usually be addressed even if you don’t use it.Changes requested
review.Changes requested
to indicate that you are considering some of your comments to block the PR from landing.What belongs in Node.js:
url
is there because of http
, freelist
is there because of http
, etc.async_hooks
.Continuous Integration (CI) Testing:
node-test-pull-request
most of the time. Go there now!Build with Parameters
. (If you don't see it, that probably means you are not logged in!) Click it now!CERTIFY_SAFE
box should be checked. By checking it, you are indicating that you have reviewed the code you are about to test and you are confident that it does not contain any malicious code. (We don't want people hijacking our CI hosts to attack other hosts on the internet, for example!)PR_ID
box should be filled in with the number identifying the pull request containing the code you wish to test. For example, if the URL for the pull request is https://github.com/nodejs/node/issues/7006
, then put 7006
in the PR_ID
.See the Collaborator Guide: Landing Pull Requests.
Commits in one PR that belong to one logical change should be squashed. It is rarely the case in onboarding exercises, so this needs to be pointed out separately during the onboarding.
git log ce986de829457c39257cd205067602e765768fb0 -1
doc
, notable-change
, and fast-track
labels.node-test-pull-request
CI task.PR-URL: <full-pr-url>
and appropriate Reviewed-By:
metadata.node-core-utils
automates the generation of metadata and the landing process. See the documentation of git-node
.core-validate-commit
automates the validation of commit messages. This will be run during git node land --final
of the git-node
command.