Lines Matching +full:pull +full:- +full:requests
9 confirm that they are using [two-factor authentication][]. It will not be
10 possible to add them to the organization if they are not using two-factor
13 * Suggest the new Collaborator install [`node-core-utils`][] and
21 and add them accordingly. See [Who to CC in the issue tracker][who-to-cc].
26 * [local setup](#local-setup)
27 * [project goals and values](#project-goals-and-values)
28 * [managing the issue tracker](#managing-the-issue-tracker)
29 * [reviewing pull requests](#reviewing-pull-requests)
30 * [landing pull requests](#landing-pull-requests)
35 * Make sure you have whitespace=fix: `git config --global --add
37 * Always create a branch in your own GitHub fork for pull requests
44 * `git reset --hard FETCH_HEAD`
45 * Make a new branch for each pull request you submit.
57 The project has a venue for real-time discussion:
59 * [`#nodejs-core`](https://openjs-foundation.slack.com/archives/C019Y2T6STH) on
60 the [OpenJS Foundation Slack](https://slack-invite.openjsf.org/)
67 * There are some higher-level goals and values
80 * Be nice about closing issues! Let people know why, and that issues and pull
81 requests can be reopened if necessary.
84 * There is [a bot](https://github.com/nodejs-github-bot/github-bot) that
86 so that we know what parts of the code base the pull request modifies. It is
88 irrelevant labels from pull requests and issues.
89 * `semver-{minor,major}`:
91 `semver-major` label
92 * When adding a `semver-*` label, add a comment explaining why you're adding
94 * Please add the [`author-ready`][] label for pull requests, if applicable.
96 * See [Who to CC in the issue tracker][who-to-cc].
111 * You can moderate non-collaborator posts yourself. Please
115 [full moderation policy](https://github.com/nodejs/admin/blob/main/Moderation-Policy.md).
117 …[full list of moderation team members](https://github.com/nodejs/moderation#moderation-team-member…
119 ## Reviewing pull requests
124 pull request from a new contributor is an opportunity to grow the community.
127 * It is tempting to micro-optimize. Don't succumb to that temptation. We
133 * Nits (requests for small changes that are not essential) are fine, but try to
134 avoid stalling the pull request.
136 * If they are stalling the pull request, fix them yourself on merge.
143 * There is a minimum waiting time which we try to respect for non-trivial
146 * For non-trivial changes, leave the pull request open for at least 48 hours.
147 * If a pull request is abandoned, check if they'd mind if you took it over
152 a pull request using GitHub's approval interface
155 * You cannot approve your own pull requests.
163 comments to block the pull request from landing.
178 * You will be using `node-test-pull-request` most of the time. Go there now!
179 * Consider bookmarking it: <https://ci.nodejs.org/job/node-test-pull-request/>
189 * The `PR_ID` box should be filled in with the number identifying the pull
191 the pull request is `https://github.com/nodejs/node/issues/7006`, then put
194 * If you need help with something CI-related:
198 ## Landing pull requests
200 See the Collaborator Guide: [Landing pull requests][].
202 Commits in one pull request that belong to one logical change should
206 <!-- TODO(joyeechueng): provide examples about "one logical change" -->
208 ## Exercise: Make a pull request adding yourself to the README
213 `git show --format=%B 6669b3857f0f43ee0296eb7ac45086cd907b9e94`
216 * Add the `Fixes: <collaborator-nomination-issue-url>` to the commit message
219 * Label your pull request with the `doc`, `notable-change`, and `fast-track`
220 labels. The `fast-track` label should cause the Node.js GitHub bot to post a
221 comment in the pull request asking collaborators to approve the pull request
223 * Optional: Run CI on the pull request. Use the `node-test-pull-request` CI
224 task. As a convenience, you may apply the `request-ci` label to the pull
227 for fast-tracking, land the PR.
229 single approval of the onboarding TSC member sufficient, and land the pull
231 * Be sure to add the `PR-URL: <full-pr-url>` and appropriate `Reviewed-By:`
233 * [`node-core-utils`][] automates the generation of metadata and the landing
234 process. See the documentation of [`git-node`][].
235 * [`core-validate-commit`][] automates the validation of commit messages.
236 This will be run during `git node land --final` of the [`git-node`][]
252 Node.js project, where we have face-to-face discussions about our work on the
257 access to the projects coverity project as outlined in [static-analysis][].
260 [Labels]: doc/contributing/collaborator-guide.md#labels
261 [Landing pull requests]: doc/contributing/collaborator-guide.md#landing-pull-requests
262 …zation membership]: https://help.github.com/articles/publicizing-or-hiding-organization-membership/
263 [`author-ready`]: doc/contributing/collaborator-guide.md#author-ready-pull-requests
264 [`core-validate-commit`]: https://github.com/nodejs/core-validate-commit
265 [`git-node`]: https://github.com/nodejs/node-core-utils/blob/HEAD/docs/git-node.md
266 [`node-core-utils`]: https://github.com/nodejs/node-core-utils
267 [set up the credentials]: https://github.com/nodejs/node-core-utils#setting-up-github-credentials
268 [static-analysis]: doc/contributing/static-analysis.md
269 [two-factor authentication]: https://help.github.com/articles/securing-your-account-with-two-factor…
270 …ile app]: https://help.github.com/articles/configuring-two-factor-authentication-via-a-totp-mobile…
271 [who-to-cc]: doc/contributing/collaborator-guide.md#who-to-cc-in-the-issue-tracker