-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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: clarify the review and landing process #10202
Conversation
a11a8b6
to
c4ff032
Compare
@@ -245,13 +251,27 @@ If in doubt, you can always ask for guidance in the Pull Request or on | |||
Feel free to post a comment in the Pull Request to ping reviewers if you are | |||
awaiting an answer on something. | |||
|
|||
Notes: if the reviewer mentions *nits* in their comments, that stands for |
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 don't think "stands for" is the right wording. That makes it sound like 'nits' is an acronym, which it isn't.
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.
Thank you for pointing this out. I'm not a native speaker so this is really helpful. Does "means" sounds better?
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.
Yes, that would sound better.
@@ -245,13 +251,27 @@ If in doubt, you can always ask for guidance in the Pull Request or on | |||
Feel free to post a comment in the Pull Request to ping reviewers if you are | |||
awaiting an answer on something. | |||
|
|||
Notes: if the reviewer mentions *nits* in their comments, that stands for | |||
"requests for small changes that are not essential". Usually these nits are |
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'm not sure the description is quite accurate. IMHO nits are just minor issues, whether the changes needed to address the minor issue are large or small is irrelevant. For example, comment typos for a PR that changes code would probably be considered a nit especially because comments don't affect the code, but it could be there are a lot of typos to fix or just one.
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.
Hmm.. I copied this phrase from the onboarding guide, maybe that one needs to be more accurate too?
How does "request for changes that are not essential" sound?
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.
That sounds better I think.
there is consensus (no objections from a Collaborator), a | ||
Collaborator can merge the Pull Request . GitHub often shows the Pull Request as | ||
A Pull Request needs to be reviewed and approved by at least one Node.js | ||
Collaborators (often by saying LGTM, or Looks Good To Me) to get landed. |
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.
It might be worth also noting Github's PR review mechanism too if we want to advocate its usage.
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.
Does adding a link to the video tutorial(https://www.youtube.com/watch?v=HW0RPaJqm4g) and the documentation(https://help.github.com/articles/reviewing-changes-in-pull-requests/) suffice?
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.
That might be a good start.
I think we may want to add some text about the validity of approvals (either via 'LGTM' or Github's PR review) after changes were made since the approval. For example, when someone approves a PR using Github's mechanism, it will still show "Approved" even after someone pushes more changes after that approval is made, which can be misleading (at least at first glance).
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.
Notes added. Thanks for the suggestion!
But, if there are non-trivial changes in this Pull Request, it still | ||
needs to wait for at least another 48 hours (72 hours on a weekend). | ||
|
||
GitHub often shows the Pull Request as | ||
`Closed` at this point, but don't worry. If you look at the branch you raised |
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.
The indentation is off here and possibly other places below.
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.
Addressed. Thanks for pointing this out.
one commit, with metadata added to the commit message (including links to the | ||
Pull Request and the names of the reviewers). This will be done by someone who | ||
has the commit access to the repository. The commit history of your Pull | ||
Request, however, will stay intact on the Pull Request page. |
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.
This isn't actually true, the commit history of your PR is available until you delete your fork branch, at which point it disappears.
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.
Thank you for pointing this out. Maybe "The commit history of your Pull Request, however, will stay intact on the Pull Request page(as long as you don't delete your fork branch, at which point it disappears)." is more accurate?
@@ -237,6 +237,12 @@ $ git commit --amend | |||
$ git push --force-with-lease origin my-branch | |||
``` | |||
|
|||
When the commits in your Pull Request get landed, they will be squashed into | |||
one commit, with metadata added to the commit message (including links to the |
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.
The commits won't necessarily be squashed into one commit per PR, they'll be squashed into one commit per logical change (it's hard to specify what a logical change is).
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.
Hmmm..maybe suggesting the new contributors checkout the previous commits to have an idea about the size of a logical change? Or a link to a specific example(preferably one with lib, src, doc, test changes but is still one logical change)?
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 think this one could be a good example. #2921 Although it's two logical changes.
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.
Ooops, strike that, that one landed as two commits too. I will try to dig up a better example(any help would be appreciated!).
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.
OK, I think this commit 0b5191f could be a good example. There are a lot of lines changed, but it's still one logical change.
@@ -237,6 +237,19 @@ $ git commit --amend | |||
$ git push --force-with-lease origin my-branch | |||
``` | |||
|
|||
When the commits in your Pull Request get landed, they will be squashed into | |||
one commit per logical change, with metadata added to the commit message | |||
(including links to the Pull Request and the names of the reviewers). |
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.
links to the pull request and relevant issues
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.
Thanks, I will add this to the sentence.
your Pull Request against (probably `master`), you should see a commit with | ||
your name on it. Congratulations and thanks for your contribution! | ||
A Pull Request needs to be reviewed and approved by at least one Node.js | ||
Collaborators (often by saying LGTM, or Looks Good To Me) to get landed. |
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.
Collaborator? Also, collaborators can use GitHub's Approve button.
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.
Do you mean this should be singular? I will add a phrase mentioning the Approve button, thanks
- Explains what "nits" stand for - Explains commit squashing - Mentions the CI run - Mentions the mandatory 48/72 hours wait - Mention GitHub's PR review feature - Fix indentation
a248e7d
to
cc22d35
Compare
@thefourtheye Thank you for the review, I've updated the changes, PTAL. |
- Mention the "landed in <sha>" comment when a PR gets landed
I have read this one more time, and I think the comment "landed in <sha>" used by collaborators when a PR gets landed should be mentioned as well. |
023d78e
to
86d6d7b
Compare
Ping. Is there anything that needs to be addressed? |
|
||
A Pull Request needs to stay open for at least 48 hours (72 hours on a | ||
weekend) from when it is submitted, even after it gets approved and | ||
passes the CI. This is to make sure that everyone has a chance to |
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.
Microscopic nit: There is a trailing space at the end of this line.
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.
Should have trimmed the spaces :P. Addressed. Thanks!
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.
Still LGTM
Landed in 44b38bb Thanks a lot @joyeecheung |
Adds/mentions: - Link to glossary - Commit squashing and CI run - 48/72 hour wait and PR review feature - Extra notes section - "Landed in <sha>" comment PR-URL: #10202 Ref: #10151 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Evan Lucas <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]>
Adds/mentions: - Link to glossary - Commit squashing and CI run - 48/72 hour wait and PR review feature - Extra notes section - "Landed in <sha>" comment PR-URL: #10202 Ref: #10151 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Evan Lucas <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]>
Adds/mentions: - Link to glossary - Commit squashing and CI run - 48/72 hour wait and PR review feature - Extra notes section - "Landed in <sha>" comment PR-URL: #10202 Ref: #10151 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Evan Lucas <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]>
Adds/mentions: - Link to glossary - Commit squashing and CI run - 48/72 hour wait and PR review feature - Extra notes section - "Landed in <sha>" comment PR-URL: #10202 Ref: #10151 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Evan Lucas <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]>
Adds/mentions: - Link to glossary - Commit squashing and CI run - 48/72 hour wait and PR review feature - Extra notes section - "Landed in <sha>" comment PR-URL: #10202 Ref: #10151 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Evan Lucas <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]>
Adds/mentions: - Link to glossary - Commit squashing and CI run - 48/72 hour wait and PR review feature - Extra notes section - "Landed in <sha>" comment PR-URL: #10202 Ref: #10151 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Evan Lucas <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]>
Adds/mentions: - Link to glossary - Commit squashing and CI run - 48/72 hour wait and PR review feature - Extra notes section - "Landed in <sha>" comment PR-URL: #10202 Ref: #10151 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Evan Lucas <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]>
Adds/mentions: - Link to glossary - Commit squashing and CI run - 48/72 hour wait and PR review feature - Extra notes section - "Landed in <sha>" comment PR-URL: #10202 Ref: #10151 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Evan Lucas <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]>
Adds/mentions: - Link to glossary - Commit squashing and CI run - 48/72 hour wait and PR review feature - Extra notes section - "Landed in <sha>" comment PR-URL: #10202 Ref: #10151 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Evan Lucas <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]>
Adds/mentions: - Link to glossary - Commit squashing and CI run - 48/72 hour wait and PR review feature - Extra notes section - "Landed in <sha>" comment PR-URL: #10202 Ref: #10151 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Evan Lucas <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]>
Checklist
Affected core subsystem(s)
doc
Description of change
A few process-related details are only explained in the onboarding guide and the collaborator's guide. Mentioning them in the contributing guide as well can avoid confusions to new contributors.
This is based on my previous experience, but I am still a new contributor myself, so feel free to correct me if my understanding is not the case!
Ref: #10151