+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 > >
