> Correcting typos, docs, website, and comments etc operate a “Commit Then > Review” policy
I think these are already covered by the current policy I would even be fine with including minor test-only fixes under this more permissive policy On 2026/09/25 14:15:18 Josh McKenzie wrote: > > 4. Code modifications made solely to existing tests, documentation, or > > comments only require one non-author +1 committer vote. > wdyt about the revision including Shailaja's feedback? > > On Fri, Sep 25, 2026, at 5:32 AM, Shailaja Koppu via dev wrote: > > +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. > > >>>>>>>>> > > >>>>>>>> > > >>>>>> > > > >
