Reviewing a Pull Request

https://www.elastic.co/blog/art-of-pull-request

PreviousWriting a Pull Request

Last updated 6 years ago

Reviewing a Pull Request

https://www.elastic.co/blog/art-of-pull-request

Understand the issue that is being fixed, or the feature being added. Check the description on the pull, and check out the related issue. If you don’t understand something, ask the submitter for clarification.
Reproduce the bug (or the lack of feature I guess?) in the destination branch, usually development. The referenced issue will help you here. If you’re unable to reproduce the issue, contact the issue submitter for clarification.
Check out the pull and test it. Is the issue fixed? Does it have nasty side effects? Try to create suspect inputs. If it operates on the value of a field try things like: strings (including an empty string), null, numbers, dates. Try to think of edge cases that might break the code.
Merge the target branch. It is possible that tests or the linter have been updated in the target branch since the pull was submitted. Merging the pull could cause core to start failing.
Read the code. Understanding the changes will help you find additional things to test. Contact the submitter if you don’t understand something.
Go line-by-line. Are there violations? Strangely named variables? Magic numbers? Do the abstractions make sense to you? Are things arranged in a testable way?
Speaking of tests Are they there? If a new function was added does it have tests? Do the tests, well, TEST anything? Do they just run the function or do they properly check the output?
Suggest improvements If there are changes needed, be explicit, comment on the lines in the code that you’d like changed. You might consider suggesting fixes. If you can’t identify the problem, animated screenshots can help the review understand what’s going on.
Hand it back If you found issues, re-assign the submitter to the pull to address them. Repeat until mergable.
Hand it off If you’re the first reviewer and everything looks good but the changes are more than a few lines, hand the pull to someone else to take a second look. Again, try to find the right person to assign it to.
Merge the code When everything loos good, merge into the target branch. Check the labels on the pull to see if backporting is required, and perform the backport if so.

PreviousWriting a Pull Request

Last updated 6 years ago

Understand the issue that is being fixed, or the feature being added. Check the description on the pull, and check out the related issue. If you don’t understand something, ask the submitter for clarification.
Reproduce the bug (or the lack of feature I guess?) in the destination branch, usually development. The referenced issue will help you here. If you’re unable to reproduce the issue, contact the issue submitter for clarification.
Check out the pull and test it. Is the issue fixed? Does it have nasty side effects? Try to create suspect inputs. If it operates on the value of a field try things like: strings (including an empty string), null, numbers, dates. Try to think of edge cases that might break the code.
Merge the target branch. It is possible that tests or the linter have been updated in the target branch since the pull was submitted. Merging the pull could cause core to start failing.
Read the code. Understanding the changes will help you find additional things to test. Contact the submitter if you don’t understand something.
Go line-by-line. Are there violations? Strangely named variables? Magic numbers? Do the abstractions make sense to you? Are things arranged in a testable way?
Speaking of tests Are they there? If a new function was added does it have tests? Do the tests, well, TEST anything? Do they just run the function or do they properly check the output?
Suggest improvements If there are changes needed, be explicit, comment on the lines in the code that you’d like changed. You might consider suggesting fixes. If you can’t identify the problem, animated screenshots can help the review understand what’s going on.
Hand it back If you found issues, re-assign the submitter to the pull to address them. Repeat until mergable.
Hand it off If you’re the first reviewer and everything looks good but the changes are more than a few lines, hand the pull to someone else to take a second look. Again, try to find the right person to assign it to.
Merge the code When everything loos good, merge into the target branch. Check the labels on the pull to see if backporting is required, and perform the backport if so.