Just as an aside. The confusion in this thread reminds me of a todo I had several months ago when I was trying to clear the backlog in our Github PRs. I participate in some CNCF projects, and as a feature for each project, they run a series of health checks. I actually wonder if we are overdoing things on the simple changes. Seems like an easy report to generate. I'll take that on as a todo and see if I can create anything helpful.
Patrick On Fri, Sep 25, 2026 at 9:27 AM Caleb Rackliffe <[email protected]> wrote: > In the VOTE thread, I've just simplified to something like my original > wording. I find it highly unlikely that a committer would commit a test fix > without verifying CI results and taking a quick look at the change itself. > If a change is really as trivial as correcting a typo in a test or > something along those lines, the existing CTR policy seems relevant. > > On Fri, Sep 25, 2026 at 11:20 AM Shailaja Koppu via dev < > [email protected]> wrote: > >> Is this ‘Commit Then Review’ available for non-committers? If not, can we >> please add CTR or +1 reviewer requirement for non-committers for this case? >> >> Correcting typos, docs, website, and comments etc operate a “Commit Then >> Review” policy >> >> >> >> >> On Sep 25, 2026, at 5:05 PM, Caleb Rackliffe <[email protected]> >> wrote: >> >> I'll start a VOTE thread... >> >> On Fri, Sep 25, 2026 at 11:03 AM Brandon Williams <[email protected]> >> wrote: >> >>> This is a DISCUSS thread, for the record should we have a VOTE? >>> >>> Kind Regards, >>> Brandon >>> >>> On Thu, Sep 24, 2026 at 8:57 PM Caleb Rackliffe >>> <[email protected]> wrote: >>> > >>> > Alright, so I guess it's >>> https://cwiki.apache.org/confluence/spaces/CASSANDRA/pages/158863606/Cassandra+Project+Governance >>> > >>> > What I would add is a new entry: >>> > >>> > 4. Code modifications made solely to existing tests require one >>> non-author +1 committer vote. >>> > >>> > On Thu, Sep 24, 2026 at 7:29 PM Caleb Rackliffe < >>> [email protected]> wrote: >>> >> >>> >> It seems like everyone agrees with the basic idea here. The question >>> is whether we actually need to codify anything/change wikis, etc. If we >>> did, what would be the best place to do that? >>> >> >>> >> I have never +1’d a patch without reviewing it, and I guess I’m >>> curious about whether I’m alone here 😅 >>> >> >>> >> > On Sep 24, 2026, at 6:33 PM, Francisco Guerrero <[email protected]> >>> wrote: >>> >> > >>> >> > Sounds reasonable to me. +1 >>> >> > >>> >> >> On 2026/09/24 23:02:03 Patrick McFadin wrote: >>> >> >> +1 >>> >> >> >>> >> >> Patrick >>> >> >> >>> >> >>>> On Sep 24, 2026, at 3:29 PM, Josh McKenzie <[email protected]> >>> wrote: >>> >> >>> >>> >> >>> >>> >> >>>> >>> >> >>>> but it would be confusing if we introduce requirements that are >>> inconsistent with those we already have. >>> >> >>> Seems like the requirements we already have are confusing to many >>> now, given some of the chatter on the other thread. >>> >> >>> >>> >> >>> I’m +1 to the above relaxations. >>> >> >>> >>> >> >>> >>> >> >>>> On Thu, Sep 24, 2026, at 5:40 PM, Benedict Elliott Smith wrote: >>> >> >>>> To reiterate, currently there is no requirement for committers >>> to review a contribution. The policy is worded quite precisely: at least >>> one *contributor* must review a change, and at least two committers must >>> approve the change (one of whom may be the author). >>> >> >>>> >>> >> >>>> The approval may consist of trust that the contributor's >>> experience is appropriate for the patch in question. >>> >> >>>> >>> >> >>>> I am open to the thrust of the refinement, but it would be >>> confusing if we introduce requirements that are inconsistent with those we >>> already have. >>> >> >>>> >>> >> >>>> On 2026/09/24 19:44:34 Caleb Rackliffe wrote: >>> >> >>>>> I'm spinning this out of the other thread we have going right >>> now on LLM >>> >> >>>>> usage... >>> >> >>>>> >>> >> >>>>> I'd like to propose that we slightly change the way we deal >>> with incoming >>> >> >>>>> patches that only touch existing tests. >>> >> >>>>> >>> >> >>>>> *Current Policy (and please correct me if I've misinterpreted >>> our current >>> >> >>>>> rules)* >>> >> >>>>> >>> >> >>>>> Fixes from non-committer contributors that only touch existing >>> tests in an >>> >> >>>>> effort to stabilize them still require 2 committer reviewers >>> before commit. >>> >> >>>>> >>> >> >>>>> *Proposed Policy* >>> >> >>>>> >>> >> >>>>> Fixes of this type from non-committer contributors only require >>> one >>> >> >>>>> committer review. CI verification of the effectiveness of the >>> fix is still >>> >> >>>>> required, etc. >>> >> >>>>> >>> >> >>>>> ... >>> >> >>>>> >>> >> >>>>> That's it. I'm just looking for ways to make small, reasonable >>> changes that >>> >> >>>>> might free up committer bandwidth for some of the larger, more >>> >> >>>>> earth-shaking things happening right now. >>> >> >>>>> >>> >> >>>> >>> >> >> >>> >> >>
