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