> Correcting typos, docs, website, and comments etc operate a “Commit Then > Review” policy Oof; words are hard. I read this as "correcting typos in docs, typos in the website, and typos in comments are 'commit then review', not "you can mutate these 3 domains w/a commit then review".
Probably because coming from a baseline of "review then commit, 2 committers on everything", the first concept that defensibly matches that text (most conservatively) is my in retrospect rather incorrect interpretation. :) Long winded way to say: I think you're right Benedict and I'd just internalized an incorrect mental model of the above. I'm wary of commit-then-review on tests; our tests can be pretty hairy / nasty / racy / complex, so at least having a single review on a test fix seems like it might be worthwhile. If we formalized multiplexing tests fixes and integrated jacoco coverage w/a requirement bar + some kind of allowable pmd / static analysis complexity ceiling in our checkstyle process for changes, I think this could work. On Fri, Sep 25, 2026, at 10:57 AM, Benedict Elliott Smith wrote: > Sorry, missed your earlier message! Yes, agreed, this would seem simpler all > round. > > Obviously, this covers the proposed scenario of a non-committer change, since > a committer must actually merge the change anyway. > > > On 2026/09/25 14:51:07 Brandon Williams wrote: > > On Fri, Sep 25, 2026 at 9:48 AM Benedict Elliott Smith > > <[email protected]> wrote: > > > > > > > Correcting typos, docs, website, and comments etc operate a “Commit > > > > Then Review” policy > > > > > > I would even be fine with including minor test-only fixes under this more > > > permissive policy > > > > This is what I was referring to earlier, and I agree. > > > > Kind Regards, > > Brandon > > >
