Improve the efficiency of code review process within team
- Escalation sometimes works with different teams, so sometimes its it's unclear whom to ask for code review:
- We can hipchat the PR in a specific room related to the domain and ask someone, who is interested in this PR to review.
- If
somone - someone does not take
inititative- initiative?
Answer- initiative?
- then we follow the traditional pattern of tagging someone on PR
- Code review process can be fasterif
- faster if the ticket is properly groomed because sometimes discussion starts on the PR' and it delays review.
- Major refactoring of solution provided for a particular issue might be avoided by discussing solution with teammates or anyone on board before implementing it.
- It's a 12hr turnaround, between Cambridge and Lahore teams, Lahore team could tag people among ourselves to get at least one initial review started.
- Encourage reviews to be done within Lahore team.
- If someone is busy and can't find time for review, he or she can refer for review to someone else.
- We may have another column(tag) for an issue named something like 'Review Needed' in JIRA board, so anyone can pick it up and review it.
- Mostly, people are busy with their sprints, we could circulate an email to the engineering department to discuss if tagging their team members is an option?.
- We could identify clearly who are the reviewers and other people who might be interested in a particular PR. If the PR gets accepted by identified reviewers, we could just merge it and not wait for others if have not received any concern from them.
- When we tag someone for review, we could add the timeline for the reviewers, if they have time they can review it otherwise they can simply excuse.
- We should follow the PR template /wiki/spaces/TNL/pages/38863270:
- Sometimes reviewers don't know the details and also request for Sandbox. If not given details or have created sandbox on PR creation; it would delay review cycle.