If someone is trusted enough to review a committers code shouldn't they
also be trusted enough to review another contributors code? As a
non-committer I would get much quicker reviews if I could have other
non-committers do the review, then get a committer who trusts us to merge.

Andrew

On Thu, May 31, 2018 at 9:03 AM Henning Rohde <hero...@google.com> wrote:

> +1
>
> On Thu, May 31, 2018 at 8:55 AM Thomas Weise <t...@apache.org> wrote:
>
>> +1 to the goal of increasing review bandwidth
>>
>> In addition to the proposed reviewer requirement change, perhaps there
>> are other ways to contribute towards that goal as well?
>>
>> The discussion so far has focused on how more work can get done with the
>> same pool of committers or how committers can get their work done faster.
>> But ASF is really about "community over code" and in that spirit maybe we
>> can consider how community growth can lead to similar effects? One way I
>> can think of is that besides code contributions existing committers and
>> especially the PMC members can help more towards growing the committer
>> base, by mentoring contributors and helping them with their contributions
>> and learning the ASF way of doing things. That seems a way to scale the
>> project in the long run.
>>
>> I'm not super excited about the concepts of "owner" and "maintainer"
>> often found in (non ASF) projects like Kenn mentions. Depending on the
>> exact interpretation, these have the potential of establishing an
>> artificial barrier and limiting growth/sustainability in the contributor
>> base. Such powers tend to be based on historical accomplishments vs.
>> current situation.
>>
>> Thanks,
>> Thomas
>>
>>
>> On Thu, May 31, 2018 at 7:35 AM, Etienne Chauchot <echauc...@apache.org>
>> wrote:
>>
>>> Le jeudi 31 mai 2018 à 06:17 -0700, Robert Burke a écrit :
>>>
>>> +1 I also thought this was the norm.
>>>
>>>  My read of the committer/contributor guide was that a committer
>>> couldn't unilaterally merge their own code (approval/LGTM needs to come
>>> from someone  familiar with the component), rather than every review needs
>>> two committers. I don't recall a requirement than each PR have two
>>> committees attached, which I agree is burdensome especially for new
>>> contributors.
>>>
>>> Yes me too, I thought exactly the same
>>>
>>>
>>> On Wed, May 30, 2018, 2:23 PM Udi Meiri <eh...@google.com> wrote:
>>>
>>> I thought this was the norm already? I have been the sole reviewer a few
>>> PRs by committers and I'm only a contributor.
>>>
>>> +1
>>>
>>> On Wed, May 30, 2018 at 2:13 PM Kenneth Knowles <k...@google.com> wrote:
>>>
>>> ++1
>>>
>>> This is good reasoning. If you trust someone with the committer
>>> responsibilities [1] you should trust them to find an appropriate reviewer.
>>>
>>> Also:
>>>
>>>  - adds a new way for non-committers and committers to bond
>>>  - makes committers seem less like gatekeepers because it goes both ways
>>>  - might help clear PR backlog, improving our community response latency
>>>  - encourages committers to code*
>>>
>>> Kenn
>>>
>>> [1] https://beam.apache.org/contribute/become-a-committer/
>>>
>>> *With today's system, if a committer and a few non-committers are
>>> working together, then when the committer writes code it is harder to get
>>> it merged because it takes an extra committer. It is easier to have
>>> non-committers write all the code and the committer just does reviews. It
>>> is 1 committer vs 2 being involved. This used to be fine when almost
>>> everyone was a committer and all working on the core, but it is not fine
>>> any more.
>>>
>>> On Wed, May 30, 2018 at 12:50 PM Thomas Groh <tg...@apache.org> wrote:
>>>
>>> Hey all;
>>>
>>> I've been thinking recently about the process we have for committing
>>> code, and our current process. I'd like to propose that we change our
>>> current process to require at least one committer is present for each code
>>> review, but remove the need to have a second committer review the code
>>> prior to submission if the original contributor is a committer.
>>>
>>> Generally, if we trust someone with the ability to merge code that
>>> someone else has written, I think it's sensible to also trust them to
>>> choose a capable reviewer. We expect that all of the people that we have
>>> recognized as committers will maintain the project's quality bar - and
>>> that's true for both code they author and code they review. Given that, I
>>> think it's sensible to expect a committer will choose a reviewer who is
>>> versed in the component they are contributing to who can provide insight
>>> and will also hold up the quality bar.
>>>
>>> Making this change will help spread the review load out among regular
>>> contributors to the project, and reduce bottlenecks caused by committers
>>> who have few other committers working on their same component. Obviously,
>>> this requires that committers act with the best interests of the project
>>> when they send out their code for reviews - but this is the behavior we
>>> demand before someone is recognized as a committer, so I don't see why that
>>> would be cause for concern.
>>>
>>> Yours,
>>>
>>> Thomas
>>>
>>>
>>

Reply via email to