[Rhodee]

:wave: Pull Request reviewer here with over 1000 reviews.

I've reviewed code across languages, team size and maturity. A good static analysis tool is not code review. The word 'context' came up 37 times in this thread (by the time I hit submit) and it is worth digging in to how I build and maintain context with teams. First up, it is my responsibility to uphold, not define a team's best current practices. If you believe a linter and static analysis tools are best current practices, you probably do not need code review. The code review process is an exercise to affirm how well a pull request meets the expectations (context) of a team and suggest remediation where appropriate.

I assume 'context' used in the threads to mean "how we do things here". As a reviewer, I conduct review understanding the problems the team wants its code reviews to optimize for or to avoid. This is due to the people creating the platform. It's a solid platform for reviewers to get things done. Every line of contributed code I review is done with an eye towards ensuring it affirms a team's stated objectives. If those objectives somehow falls outside of what I know to be true from my experiences as a professional and best current practices (BCP), I am empowered to engage the team.

I've had teams request to never provide guidance for coding style issues. Others want to know if how they modeled a React component tree could be improved. My success on the platform relies on always building context. Without that rapport it limits the depth of the review. Because code reviews are interactive, they tend to get better over time. When things go well, the relationship between team and reviewer is seeking a pareto optimum between the pull request and the team's best current practices. When needs change I adapt my reviews. It is the same treatment if you're a one person shop, SME or a listed company.

k thx bye

[zild3d]

I thought of context to be more about domain/tribal knowledge rather than just "how we do things here".

You can be a ruby expert, but to review a ruby PR for Stripe's backend I think you'd need to know a lot about the various internal systems, downstream users, etc that the code impacts