+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*.
>
> +1
>
> On Fri, 25 Sept 2026 at 08:14, Bernardo Botella
>>
>> +1
>>
>>>
>>>
>>> What I would add is a new entry:
>>>
>>> 4. Code modifications made solely to existing tests require one non-author +1 committer vote.
>>>
>>>>
>>>> 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 😅
>>>>
>>>>>
>>>>> Sounds reasonable to me. +1
>>>>>
>>>>>> On 2026/09/24 23:02:03 Patrick McFadin wrote:
>>>>>> +1
>>>>>>
>>>>>> Patrick
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>
>>>>>>
