In my previous job we went through the same process. A review involves two parties (the author and the reviewers) with different goals and obligations. Fast for

In my previous job we went through the same process. A review involves two parties (the author and the reviewers) with different goals and obligations. Fast forward, we decided that the goal of a reviewer is to check - readability/maintainability - coding style All other things (e.g. linting, formatting, simple error checks...) have to be automated, cause this is super anoying. > As a general rule, keep the process lightweight, it should not be a burden, make it a fun activity. Here are some more question that came up: - Whats a good size for a review -- something up to 400 LOC, there are papers on that topic - How long can the author wait, hence how often to reviewers have to review -- we tried to establish a habbit to do reviews twice a day - How many people have to accept? -- this question is interesting, cause there is a correlation of number of reviewers and bad review quality. - Who is reviewer -- opt-in, if knowledge sharing is your goal, keep it open. There are companies that mark branches in the source code with OWNER files to make this more explicit - Are there mandatory reviewers -- yes, the owner should give his approval, unless he is on holiday - How do you resolve discussions (and are they efficient)? -- IMO pairing on non-trivial comments was the most efficient approcah. - If you are unhappy, can you decline a review? -- that would be brutal - How do you communicate/notify people? - How do you handle late comments? if you use pull requests, reviewers could still comment? - To resolve a comment in the review you changed the code and revoke all approvals? - Do you want to enforce behavior -- just make it a fun activity :)