See thread "Checkstyle as style contract for Cassandra 
<https://lists.apache.org/thread/8lzlc4x6g6yx766w738grxdcmqgwds7l>".

One area where we haven't formalized much guidance is around our code review 
culture as a project. I've worked with guides based on google's "How to do a 
code review <https://google.github.io/eng-practices/review/reviewer/>" 
eng-practices in the past with some success. In the above thread, while there's 
a lot of interconnected concerns (do we rely on checkstyle to enforce style, 
how are new people on the project expected to learn about style or get involved 
reviewing code, etc), we can split out the review piece to its own discussion.

We currently have a fairly extensive guide on our Code Style 
<https://cassandra.apache.org/_/development/code_style.html#:~:text=The%20Cassandra%20project%20follows%20Sun's,have%20accumulated%20in%20different%20subsystems.>.
 Should we do the same around how to review and, if so, should we start with an 
existing artifact or from scratch?

Reply via email to