I agree that automatic assignment is an imperfect tool. It’s difficult to know what functional area (let alone module) a bug or feature belongs to, and even then, who is the “owner” of that area. But it’s worth a try.
We have quite a good process going for release managers: people sign up in advance for a particular release (which I’d estimates takes between 1 and 3 days, on average) and they deliver on their commitment. Could we emulate that for reviewers? Suppose that six committers volunteer to review and merge up to six PRs per quarter. When they’ve done their six, we stop assigning them new ones. Reviewers can re-assign to another reviewer, but if you’re the assigned reviewer the ball is in your court to drive the PR to completion if the contributor makes any reasonable changes you ask for. In addition, we should consider appointing a ‘controller’ who assigns PRs to reviewers when they arrive. We could rotate the controller so that no one serves for more than a few weeks. Assigning people to tasks may seem antithetical to the spirit of open source. But it’s what effective software development teams do. It’s not creating more work, it’s just apportioning that work more fairly, and making things more predictable for our the people who depend on us. Julian > On Feb 7, 2022, at 1:56 PM, Stamatis Zampetakis <[email protected]> wrote: > > Hello, > > I think the main problem is still the lack of active committers/reviewers > and not so much the assignment. > > Nevertheless, things would be a bit better if we had people assigned to > PRs. This could certainly help at least offload some work from Julian and > possibly sensibilize more people towards the reviewing process. > > We could opt for assigning PRs automatically using filename patterns. This > can be done rather easily and it's already done in various projects e.g., > Hive [1]. > > What do you think of putting automatic assignment in place for Calcite? > Who is willing to put their name in the list? At this point I am not > expecting that people in the list will review everything they are assigned > on but maybe they can help out by pointing to other people or simply > setting up the expectations about the PR getting reviewed. > > Best, > Stamatis > > [1] > https://github.com/apache/hive/commit/2bd6a9d63c28e5cb9bcc44115262d565cdc2bb90 > > > On Sat, Feb 5, 2022 at 5:52 PM Jing Zhang <[email protected]> wrote: > >> Hi, Julian >> There is no doubt that you are the most prolific contributors on the >> project. >> People often hope to hear professional advice from you because you are the >> Calcite project authority. >> However people may didn't realize that you are suffering from more and more >> requests. I want to sincerely apologize because I often disturb you too. >> I'm really glad to hear your feelings. >> At the same time, I want to thank you because I got many professional >> advices from you. The suggestions are very helpful. >> >> Back to this topic, having an efficient mechanism to merge contributors' PR >> is very important to the long-term development of open source projects. >> I would like to share my thoughts, hope it helps. >> 1. It might helpful to know which members are proficient in which modules. >> For example, introduce each member's familiar module on the website[1]. >> There may be many requests sent to other members. >> 2. For some modules, perhaps only very few members are familiar. (For >> example, when it comes to modifying the parser grammar, someone may want to >> hear from Julian, and when it comes to hints, someone may want to hear from >> Danny.) Maybe it's just my bias. But if this is the real situation, is it >> possible to develop more than one members on each module? >> 3. It could be helpful to assign reviewers for a new pull request. >> >> [1] https://calcite.apache.org/community/#project-members >> >> Best, >> Jing Zhang >> >> Julian Hyde <[email protected]> 于2022年2月4日周五 02:18写道： >> >>> I make many contributions to this project, in the form of code, >>> answering questions, leading design discussions, and clarifying bugs >>> and feature requests. I review more changes than any other project >>> member. My reward is that I am pestered, daily, with people pleading >>> for me to review their changes. >>> >>> It's moderately annoying for me - I just delete the emails (because I >>> have 200 other emails to delete before I can start productive work). >>> But it's awful for both the contributors and the project. >>> >>> Getting PRs reviewed is this project's biggest problem, and has been for >>> years. >>> >>> Many of you are team leads, engineering managers, directors of >>> engineering. This is a process problem. Solving problems like this is >>> what you do. Fix it. >>> >>> Julian >>> >>
