...
When a pull request is made against , https://github.com/kuali/kfs, the the financials git repository the product team will be notified. At least one member of the product team will review, though several members may review if the pull requests warrants that level of scrutiny.
When a Pull Request is submitted, the unit tests will be run against the code. The the tests fail, the code will need to be fixed, pushed to the pull request and then retested. To trigger a new unit test on the changes, you can write a comment on the pull request with the text jenkins, retest this please. The product team will review the pull request after the tests succeed.
If the product team reviewer has questions about the code under review, they'll respond in one of a couple of different venues. We anticipate that most responses will be comments on the pull request itself. If the responses merits a more direct discussion, that discussion will take place either in slack or in the meeting after the appropriate stand-up.
Outstanding questions or concerns on a pull request must be addressed by the code author; otherwise, the pull request will not be merged by the product team.In time, the product team is hopeful that a certain amount of automated testing - running the PreCommitSuite for starters or possibly even the full unit test suite for the module(s) being committed to, along with doing certain style checks - will be done as soon as the pull request is created, without the product team even concerning themselves with it until all of those automatic checks pass.
Ad-hoc Code Reviews
If code is of a sufficient complexity, the reviewer(s) on the product team may call for a code review meeting. The product team engineers will set up a time to meet with the authors of the code. Meetings will likely be held on hangouts, where screens can be shared and audio provides a more direct means of communication.