+1 for tests and any non-code PRs like docs/readme/comments etc. This will help unemployed engineers trying to show OSS experience in their resume or employed engineers trying to increase their breadth etc during onboarding to C*.
> On Sep 25, 2026, at 8:12 AM, Maxim Muzafarov <[email protected]> wrote: > > +1 > > On Fri, 25 Sept 2026 at 08:14, Bernardo Botella > <[email protected]> wrote: >> >> +1 >> >> El vie, 25 sept 2026 a las 3:57, Caleb Rackliffe >> (<[email protected]>) escribió: >>> >>> 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. >>>>>>>>> >>>>>>>> >>>>>>
