Yes i do whenever possible - that is, if the team i work with as a freelancer already does or is willing to follow my advice to do it. That is - disturbingly -

Yes i do whenever possible - that is, if the team i work with as a freelancer already does or is willing to follow my advice to do it. That is - disturbingly - not always the case. I only worked with gitlab abd github pull/merge request code review tooling and found it ok. There’s Gerrit, but i had no chance to work with it yet. Obviously always depends on how they need to be done. When in doubt, just sit next to each other and look at the part of code and changes for the current task your working on that is about to be merged. Not always a special tool necessary and if you don’t know which one to use better just start than let the tool choice get in the way. That being said I’m not against tools! Suggestions? As with any process or meeting, define what the scope is! Is it about coding style? Which are your guidelines for that one then? Is it about getting a second look if the story is implemented in a good, efficient way? Is it to verify definition of done rules are met? About having (good) tests? It’s probably not (counterexample i just had) to discuss the actual requirements defined by the story the code should fulfill... that should have happened at another time, probably with other persons, like the Product Owner. How often? I think it’s best to do it with each merge request for the code it contains, and maybe in defined tinespans for the whole project.