doc: exempt test/doc only changes from 48-hr rule #16135
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
addaleax
added
doc
targos
approved these changes
Oct 11, 2017
Qard
approved these changes
Oct 11, 2017
joyeecheung
approved these changes
Oct 11, 2017
gireeshpunathil
approved these changes
Oct 11, 2017
Trott
reviewed
Oct 11, 2017
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.
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.
Maybe "small changes that affect only documentation and/or the test suite" would work?
There was a problem hiding this comment.
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
addaleax
force-pushed
the
48-hours-exempt-docs-tests
branch
from
d9c8a19 to
f6f4029
Compare
lpinca
approved these changes
Oct 11, 2017
MylesBorins
approved these changes
Oct 11, 2017
mcollina
reviewed
Oct 11, 2017
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.
I would add "if the change is approved by at least 2 collaborators". This is the typical case anyway.
evanlucas
approved these changes
Oct 11, 2017
Qard
approved these changes
Oct 11, 2017
Fishrock123
approved these changes
Oct 11, 2017
There was a problem hiding this comment.
Seems fine to me. I think I'd still prefer @mcollina's comment but I'm not certain it is necessary.
ofrobots
approved these changes
Oct 11, 2017
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.
addaleax
force-pushed
the
48-hours-exempt-docs-tests
branch
from
f6f4029 to
2d11995
Compare
fhinkel
approved these changes
Oct 12, 2017
jasnell
approved these changes
Oct 12, 2017
jasnell
pushed a commit
that referenced
this pull request
Oct 12, 2017
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 <[email protected]> Reviewed-By: Stephen Belanger <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Myles Borins <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Evan Lucas <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]> Reviewed-By: Ali Ijaz Sheikh <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Franziska Hinkelmann <[email protected]> Reviewed-By: James M Snell <[email protected]>
|
Landed in a766f6d |
addaleax
added a commit
to ayojs/ayo
that referenced
this pull request
Oct 15, 2017
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 <[email protected]> Reviewed-By: Stephen Belanger <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Myles Borins <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Evan Lucas <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]> Reviewed-By: Ali Ijaz Sheikh <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Franziska Hinkelmann <[email protected]> Reviewed-By: James M Snell <[email protected]>
targos
pushed a commit
that referenced
this pull request
Oct 18, 2017
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 <[email protected]> Reviewed-By: Stephen Belanger <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Myles Borins <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Evan Lucas <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]> Reviewed-By: Ali Ijaz Sheikh <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Franziska Hinkelmann <[email protected]> Reviewed-By: James M Snell <[email protected]>
targos
pushed a commit
that referenced
this pull request
Oct 18, 2017
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 <[email protected]> Reviewed-By: Stephen Belanger <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Myles Borins <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Evan Lucas <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]> Reviewed-By: Ali Ijaz Sheikh <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Franziska Hinkelmann <[email protected]> Reviewed-By: James M Snell <[email protected]>
4 tasks
MylesBorins
pushed a commit
that referenced
this pull request
Nov 16, 2017
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 <[email protected]> Reviewed-By: Stephen Belanger <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Myles Borins <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Evan Lucas <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]> Reviewed-By: Ali Ijaz Sheikh <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Franziska Hinkelmann <[email protected]> Reviewed-By: James M Snell <[email protected]>
Merged
MylesBorins
pushed a commit
that referenced
this pull request
Nov 21, 2017
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 <[email protected]> Reviewed-By: Stephen Belanger <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Myles Borins <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Evan Lucas <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]> Reviewed-By: Ali Ijaz Sheikh <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Franziska Hinkelmann <[email protected]> Reviewed-By: James M Snell <[email protected]>
MylesBorins
pushed a commit
that referenced
this pull request
Nov 28, 2017
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 <[email protected]> Reviewed-By: Stephen Belanger <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Myles Borins <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Evan Lucas <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]> Reviewed-By: Ali Ijaz Sheikh <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Franziska Hinkelmann <[email protected]> Reviewed-By: James M Snell <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 :)