In that case, the contributor should be a committer pretty fast. I would prefer to keep at least a final validation from a committer to guarantee the consistency of the project and anyway, only committer role can merge a PR. However, I fully agree that the most important is the Beam community. I have no problem that non committer does the review and ask a committer for final one and merge.
Regards JB On 31/05/2018 19:33, Andrew Pilloud 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 > <mailto:hero...@google.com>> wrote: > > +1 > > On Thu, May 31, 2018 at 8:55 AM Thomas Weise <t...@apache.org > <mailto: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 <mailto: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 >> <mailto: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 <mailto: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 <mailto: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 > > -- -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
