Set of guidelines for PR reviewers to guarantee a more civilized approach and avoid creating a toxic feedback culture.
Access Github Repo.
Checks are saved in your local storage
Pull request review workflow
Review the PR ASAP after being allocated to it.
Run code and use it as the end user would. Double check requests in feature’s description.
After exploring feature from your own expectations, review the "QA checklist" created by the feature’s developer in the feature card. Work on whatever hasn’t been covered.
If feature behavior is wrong, don't review code yet. Allocate PR back to developer and describe, in detail, correct feature behavior. Describe meticulously, providing screenshots and flows if applicable. Miscommunication led to misunderstanding, therefore you need to invest time in describing it better now. After explaining the issue again, mention the original issue's author for her/him to know what was done wrong.
Checklist containing what managers at Vinta have to pay attention whenever there is a sprint meeting with a client. Not all of these need to be discussed every single meeting, but they need to be clarified whenever necessary.
Checklist for everything that needs to be described and linked whenever a developer creates a new feature card on Trello so other people (or the same dev in the future) can understand the whole feature quicker.