-
Notifications
You must be signed in to change notification settings - Fork 30.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doc: exempt test/doc only changes from 48-hr rule #16135
Conversation
COLLABORATOR_GUIDE.md
Outdated
@@ -64,7 +64,8 @@ from other Collaborators. Leave at least 48 hours during the week and | |||
72 hours over weekends to account for international time differences | |||
and work schedules. Trivial changes (e.g. those which fix minor bugs | |||
or improve performance without affecting API or causing other | |||
wide-reaching impact) may be landed after a shorter delay. | |||
wide-reaching impact), and changes that affect only specific parts of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit, non-blocking: s/only specific/small/
specific may cause someone to ask "And which specific parts are those?"
(Of course "small parts" may cause someone to ask "What is small?" but the answer there is "We trust collaborator's judgment to know when a change is small or not."
If "small" is not the right word here, maybe "focused" or "localized"? (Although "localized" runs the risk of being confused with language localization.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe "small changes that affect only documentation and/or the test suite" would work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually like “focused” pretty much – e.g. a PR that refactors var
to let
/const
doesn’t need to be small but can still be focused
d9c8a19
to
f6f4029
Compare
COLLABORATOR_GUIDE.md
Outdated
@@ -64,7 +64,8 @@ from other Collaborators. Leave at least 48 hours during the week and | |||
72 hours over weekends to account for international time differences | |||
and work schedules. Trivial changes (e.g. those which fix minor bugs | |||
or improve performance without affecting API or causing other | |||
wide-reaching impact) may be landed after a shorter delay. | |||
wide-reaching impact), and focused changes that affect only documentation | |||
and/or the test suite, may be landed after a shorter delay. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would add "if the change is approved by at least 2 collaborators". This is the typical case anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mcollina done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems fine to me. I think I'd still prefer @mcollina's comment but I'm not certain it is necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but would strongly prefer @mcollina's suggestion be incorporated.
If a change affects only specific parts of the tests and or documentation, and in particular not of the runtime code itself, it should often be okay to land it early. The primary goal of the 48-hour rule is to ensure that people who are invested in certain parts of Node have a reasonable chance to weigh in based on their usage of Node; if the API is not touched in a change, that is arguably much less of an issue. In particular, this: - Should help avoid excessive nitpicking. - Helps newcomers, since their first PRs often touch only those areas and a direct success is very motivating. - Helps with the amount of pull requests created by events such a Code & Learn.
f6f4029
to
2d11995
Compare
If a change affects only specific parts of the tests and or documentation, and in particular not of the runtime code itself, it should often be okay to land it early. The primary goal of the 48-hour rule is to ensure that people who are invested in certain parts of Node have a reasonable chance to weigh in based on their usage of Node; if the API is not touched in a change, that is arguably much less of an issue. In particular, this: - Should help avoid excessive nitpicking. - Helps newcomers, since their first PRs often touch only those areas and a direct success is very motivating. - Helps with the amount of pull requests created by events such a Code & Learn. PR-URL: #16135 Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Stephen Belanger <admin@stephenbelanger.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Myles Borins <myles.borins@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Evan Lucas <evanlucas@me.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Landed in a766f6d |
If a change affects only specific parts of the tests and or documentation, and in particular not of the runtime code itself, it should often be okay to land it early. The primary goal of the 48-hour rule is to ensure that people who are invested in certain parts of Node have a reasonable chance to weigh in based on their usage of Node; if the API is not touched in a change, that is arguably much less of an issue. In particular, this: - Should help avoid excessive nitpicking. - Helps newcomers, since their first PRs often touch only those areas and a direct success is very motivating. - Helps with the amount of pull requests created by events such a Code & Learn. PR-URL: nodejs/node#16135 Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Stephen Belanger <admin@stephenbelanger.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Myles Borins <myles.borins@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Evan Lucas <evanlucas@me.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
If a change affects only specific parts of the tests and or documentation, and in particular not of the runtime code itself, it should often be okay to land it early. The primary goal of the 48-hour rule is to ensure that people who are invested in certain parts of Node have a reasonable chance to weigh in based on their usage of Node; if the API is not touched in a change, that is arguably much less of an issue. In particular, this: - Should help avoid excessive nitpicking. - Helps newcomers, since their first PRs often touch only those areas and a direct success is very motivating. - Helps with the amount of pull requests created by events such a Code & Learn. PR-URL: #16135 Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Stephen Belanger <admin@stephenbelanger.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Myles Borins <myles.borins@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Evan Lucas <evanlucas@me.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
If a change affects only specific parts of the tests and or documentation, and in particular not of the runtime code itself, it should often be okay to land it early. The primary goal of the 48-hour rule is to ensure that people who are invested in certain parts of Node have a reasonable chance to weigh in based on their usage of Node; if the API is not touched in a change, that is arguably much less of an issue. In particular, this: - Should help avoid excessive nitpicking. - Helps newcomers, since their first PRs often touch only those areas and a direct success is very motivating. - Helps with the amount of pull requests created by events such a Code & Learn. PR-URL: #16135 Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Stephen Belanger <admin@stephenbelanger.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Myles Borins <myles.borins@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Evan Lucas <evanlucas@me.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
If a change affects only specific parts of the tests and or documentation, and in particular not of the runtime code itself, it should often be okay to land it early. The primary goal of the 48-hour rule is to ensure that people who are invested in certain parts of Node have a reasonable chance to weigh in based on their usage of Node; if the API is not touched in a change, that is arguably much less of an issue. In particular, this: - Should help avoid excessive nitpicking. - Helps newcomers, since their first PRs often touch only those areas and a direct success is very motivating. - Helps with the amount of pull requests created by events such a Code & Learn. PR-URL: #16135 Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Stephen Belanger <admin@stephenbelanger.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Myles Borins <myles.borins@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Evan Lucas <evanlucas@me.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
If a change affects only specific parts of the tests and or documentation, and in particular not of the runtime code itself, it should often be okay to land it early. The primary goal of the 48-hour rule is to ensure that people who are invested in certain parts of Node have a reasonable chance to weigh in based on their usage of Node; if the API is not touched in a change, that is arguably much less of an issue. In particular, this: - Should help avoid excessive nitpicking. - Helps newcomers, since their first PRs often touch only those areas and a direct success is very motivating. - Helps with the amount of pull requests created by events such a Code & Learn. PR-URL: #16135 Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Stephen Belanger <admin@stephenbelanger.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Myles Borins <myles.borins@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Evan Lucas <evanlucas@me.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
If a change affects only specific parts of the tests and or documentation, and in particular not of the runtime code itself, it should often be okay to land it early. The primary goal of the 48-hour rule is to ensure that people who are invested in certain parts of Node have a reasonable chance to weigh in based on their usage of Node; if the API is not touched in a change, that is arguably much less of an issue. In particular, this: - Should help avoid excessive nitpicking. - Helps newcomers, since their first PRs often touch only those areas and a direct success is very motivating. - Helps with the amount of pull requests created by events such a Code & Learn. PR-URL: #16135 Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Stephen Belanger <admin@stephenbelanger.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Myles Borins <myles.borins@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Evan Lucas <evanlucas@me.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
If a change affects only specific parts of the tests and or
documentation, and in particular not of the runtime code itself,
it should often be okay to land it early.
The primary goal of the 48-hour rule is to ensure that people
who are invested in certain parts of Node have a reasonable chance
to weigh in based on their usage of Node; if the API is not
touched in a change, that is arguably much less of an issue.
In particular, this:
and a direct success is very motivating.
Code & Learn.
Checklist
Affected core subsystem(s)
@nodejs/tsc
I can’t be there but if you feel it’s worth pointing to this PR in today’s TSC meeting please do so :)