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. >> >> >>>>> >> >> >>>> >> >> >> >> > >
