-
Notifications
You must be signed in to change notification settings - Fork 30k
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: simplify pull request wait time to 48 hours #23082
Conversation
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.
sorry for the 🔧 in the 🎡 .
I strongly believe that if simplification is sought, then the timespan should be 72h.
It is my opinion that approvals are just part of the picture. Review and notification is the other. |
Well that raises another point -- I've recently seen a PR that pinged a group and then landed (with no responses either way from the group pinged) an hour later (the PR itself had been opened for long enough). If a group is pinged on a PR presumably we want to give sufficient time for that group to notice the ping and respond. |
I'd prefer to opt for the longer of the two. |
An idea for possible simplification without changes in policy. Have the bot flag issues when enough time passed. |
@richardlau FWIW, the group may be pinged if there are no sufficient approvals for the relevant PR for some time (we need 2 now). PRs may be considered ready by a lander once a second reviewer appears. Otherwise, we may need to add a rule about sufficient time after a ping. |
I am somewhat surprised that this is the conclusion when thinking about this time frame. I personally definitely do not review each PR and I would not want to either even though I definitely look at a lot of them. I rely on all fellow collaborators that everyone does a good job reviewing code. If a PR got two LGs I would not expect mine to be required at all. So why does everyone have to be responsive in 48 hours? Another point is that even if something lands and it turns out that it was a bad idea or what so ever we can still revert it. |
To echo what was said in the older, 72 hour alternative PR, I think standardizing on 72 hours is better because it works especially well for the weekend scenario, since 72 hours covers an entire weekend better when considering different people from different timezones. |
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
I'm not referring to reviewing every PR, but I would like the possibility to review every PR that interests me, or that may impact my contribution in the future.
I want to decouple Approvals from Review. IMHO review is a way for me to minimize future surprise, and also as a way for the community to acknowledge that my opinion matters.
Revert is IMHO a more aggressive act then discussion ahead of time. IMHO revert should happen only if a change hurts the project. Review and discussion are opportunities to make things optimal in the first hand. tl;dr what is the rush? When ⚖️ code quality vs velocity, I opt for quality every time. |
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.
Making it explicit for the reason previously stated.
The 72-hour alternative is at #22275. |
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.
If there's a need to simplify the current rule, I'd rather go with #22275
Since there seems to be consensus that simplification is desirable, but no consensus on whether it should be simplified to 48 or 72 hours, here's a compromise of 60 hours: #23093 |
LGTM, we can always open a PR amending or reverting the change if needed. |
One thing to also keep in mind: most PRs that are not absolutely trivial do not land after 48 hours. The PR has to receive enough LGs, all comments have to be addressed and the CI has to be green. All of these factors make it pretty difficult to land anything in that time frame that is not a simple change. |
Landed in 124a8e2 |
@Trott There are 2 more mentions to fix:
|
@vsemozhetbyt Thanks for catching that! I've now opened #23309 to update pull-requests.md. If you've already opened a PR or were planning on it, I'm happy to close mine. |
Currently, we have a 72 rule for how many hours a pull request should be left open at a minimum. Reduce that time to 48 hours. PR-URL: #23082 Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Denys Otrishko <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Franziska Hinkelmann <[email protected]> Reviewed-By: Anatoli Papirovski <[email protected]>
Currently, we have a 72 rule for how many hours a pull request should be left open at a minimum. Reduce that time to 48 hours. PR-URL: #23082 Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Denys Otrishko <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Franziska Hinkelmann <[email protected]> Reviewed-By: Anatoli Papirovski <[email protected]>
Currently, we have a 72 rule for how many hours a pull request should be left open at a minimum. Reduce that time to 48 hours. PR-URL: nodejs#23082 Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Denys Otrishko <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Franziska Hinkelmann <[email protected]> Reviewed-By: Anatoli Papirovski <[email protected]>
Currently, we have a 72 rule for how many hours a pull request should be left open at a minimum. Reduce that time to 48 hours. PR-URL: #23082 Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Denys Otrishko <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Franziska Hinkelmann <[email protected]> Reviewed-By: Anatoli Papirovski <[email protected]>
I want to say I was wrong. It seems to me that simplifying the wait time has made the review process, at least for me, indeed simpler. |
Not a change I'd want to sneak in unnoticed, so: @nodejs/collaborators
Currently, we have a 48/72 rule for how many hours a pull request should
be left open at a minimum. Unfortunately, whether a pull request should
be left open for 48 or 72 hours is often unclear. The 72 hours is
required if it is a weekend. If I open a pull request on a Friday
morning, does it need to stay open 48 hours or 72 or something in
between? Does it matter if I'm in one time zone or another?
Pull requests used to require a single approval but now require two
approvals unless they've been open for a week. Given this, it seems like
we can simplify the wait time rule to be just 48 hours.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes