+1 for the idea of reducing load on committers by involving contributors to perform detailed reviews. I think this has been the case in practice at least in some cases. I agree with Thomas Weise that proper long term solution will be growing the committer base by helping existing regular contributors to become committers.
+0 for Andrew's idea on allowing PRs where both author and contributor are non-committers. I think this should be only done in (rare) cases where we don't have a committer whose an expert in the component being modified. Thanks, Cham On Thu, May 31, 2018 at 10:34 AM Andrew Pilloud <apill...@google.com> wrote: > 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 >>>> >>>> >>>
