Well, as a growing member on this community, I definitely see benefit on such a review style guide. I’d also be more than happy to participate on its creation with my “fresh eyes reviewer” hat, as someone that hasn’t been reviewing PR for as long as other members of the community.
Having said that, coming back to Josh’s initial question around starting from an existing artifact or from scratch, I am sure we can get such an artifact and use it for inspiration and adapt it to the nuances of our project. Just to state the obvious, the review guide should not only cover Cassandra main project. It should also aim to expand to all the subprojects (such as Sidecar and analytics). Bernardo > El ene 18, 2025, a las 4:37 p.m., Ekaterina Dimitrova <e.dimitr...@gmail.com> > escribió: > > Having updated guides is great and probably we can also put links to them > into the PR template, for convenience sake. Thus anyone who opens a PR will > see them. > > On Sat, 18 Jan 2025 at 18:46, Jordan West <jw...@apache.org > <mailto:jw...@apache.org>> wrote: >> I generally support a guide we can point new contributors to as well. >> >> Jordan >> >> On Sat, Jan 18, 2025 at 10:20 Dinesh Joshi <djo...@apache.org >> <mailto:djo...@apache.org>> wrote: >>> As a growing community with new committers and contributors, I would >>> support establishing a review guide to ensure consistency and uniformity of >>> feedback. >>> >>> On Sat, Jan 18, 2025 at 5:21 AM Josh McKenzie <jmcken...@apache.org >>> <mailto:jmcken...@apache.org>> wrote: >>>> 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?
