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