On Tue, Sep 29, 2026 at 8:55 PM C. Scott Andreas <[email protected]> wrote:
> Dinesh, > > I follow the point that you are making, but your reply dismisses Jane’s > central concern without addressing it: the review burden. > I did not mean to come off as dismissive. Apologies if that's how it felt. It was unintentional. > “Software testing, certification, and verification” are orthogonal > concerns to the burden on reviewers > I don't quite see it that way. Having extensive testing, verification and robust certification processes even before reviews is a reassuring signal. Jane's concern about the burden of verifying the correctness of the patch largely falls on the reviewer. I absolutely share this concern. However, we need to shift it back this burden on the author of the patch. > and the activity of review: ensuring harmony with the overall codebase and > architecture > This is the single biggest part of the reviewer's job we cannot delegate to AI. CEPs solve some of this upfront and reduce the friction during review especially for large features. Maybe there is an opportunity to explore expanding & refining the CEP process? , replicating knowledge of the implementation among maintainers, and > refining software together. > This is the hard part. I do see this happening via CEPs, code-reviews, and annually via CoC talks. Outside of that I'm not aware of knowledge being actively replicated. Maybe I missed something but I'm not sure how a policy helps address these issues? Dinesh >
