Sorry, I'm a strong -1 for having owners or standard reviewers. In this community, we've always taken the stance that anyone should be able to jump in and help. Having assigned owners may seem like a good idea, but it actually prevents other people from volunteering and getting involved. This is also why we don't assign issues to individuals -- they often don't end up submitting a PR and it prevents other people from contributing. Having an assigned owner gives the impression that the responsibility is on a particular individual, making other people that are capable of reviewing not pay attention. I think this will slow down the community and I don't think it is a good idea.
Ryan On Tue, Mar 26, 2024 at 6:36 AM Ajantha Bhat <ajanthab...@gmail.com> wrote: > +1 for having multiple PR review owners per module/label. > > Having module owners can accelerate PR processing. For instance, I'm > awaiting feedback on a Spark action for computing partition stats ( > https://github.com/apache/iceberg/pull/9437). Currently, only Anton is > reviewing, which may cause delays if he's occupied. In my opinion, having > multiple module owners would enable developers to seek feedback more > efficiently. > > - Ajantha > > On Thu, Mar 21, 2024 at 11:11 PM Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > >> Hi folks >> >> Now that we have the proposal process "merged", I will create the PR >> about reviewers and update stale job. >> >> I should have the PR tomorrow for review. >> >> Thanks ! >> Regards >> JB >> >> On Thu, Mar 21, 2024 at 9:55 AM Jean-Baptiste Onofré <j...@nanthrax.net> >> wrote: >> > >> > Hi Dan >> > >> > Yes, I saw you merged it, that's great. >> > >> > I will move forward on the "stale bot" stuff. >> > >> > Thanks ! >> > Regards >> > JB >> > >> > On Wed, Mar 20, 2024 at 8:48 PM Daniel Weeks <dwe...@apache.org> wrote: >> > > >> > > Hey JB, apologies for combining these two things in the same thread, >> but we got enough eyes on the first PR and I went ahead and merged i >> > > >> > > If you want to put together the PR for your proposed changes, we can >> get looking at that. >> > > >> > > We'll also need to backfill the existing proposals and update the >> website to have a link to the label. (Will work with you and Bits on that) >> > > >> > > Thanks, >> > > -Dan >> > > >> > > >> > > >> > > On Wed, Mar 20, 2024 at 10:01 AM Jean-Baptiste Onofré < >> j...@nanthrax.net> wrote: >> > >> >> > >> Hi Fokko >> > >> >> > >> I think combining Dan's proposal about "proposal process" and this >> > >> proposal about "PR flows" would be helpful for the project (to track >> > >> the proposals and avoid "stale" PRs/proposals). >> > >> >> > >> If PMC members are OK, I'm ready to help to set this up :) >> > >> >> > >> Thanks >> > >> Regards >> > >> JB >> > >> >> > >> On Wed, Mar 20, 2024 at 12:27 PM Fokko Driesprong <fo...@apache.org> >> wrote: >> > >> > >> > >> > Hey everyone, >> > >> > >> > >> > This is a gentle bump from my end on this thread since I like the >> idea. Several people have already approved Dan's PR about formalizing the >> proposal process. Are there any questions or concerns from the PMC before >> adopting this? >> > >> > >> > >> > Kind regards, >> > >> > Fokko Driesprong >> > >> > >> > >> > Op wo 13 mrt 2024 om 13:17 schreef Renjie Liu < >> liurenjie2...@gmail.com>: >> > >> >> >> > >> >> Hi, JB: >> > >> >> >> > >> >> Your proposal looks great to me. We should definitely have a vote >> for a proposal impacting the spec, and the model is great. >> > >> >> >> > >> >> On Tue, Mar 12, 2024 at 10:55 PM Jean-Baptiste Onofré < >> j...@nanthrax.net> wrote: >> > >> >>> >> > >> >>> Hi >> > >> >>> >> > >> >>> I think a vote would be necessary only if we don't have >> consensus on a >> > >> >>> proposal. If anyone is OK with the proposal (no clear "concern" >> in the >> > >> >>> doc and/or the GitHub issue), a vote is not required. >> > >> >>> That said, any proposal impacting a spec should be voted (as >> part of >> > >> >>> the spec proposal). >> > >> >>> >> > >> >>> I think it's fair to identify a proposal vote as a "code >> modification" vote. >> > >> >>> It means that it follows this model: a negative vote constitutes >> a >> > >> >>> veto , which the voting group (generally the PMC of a project) >> cannot >> > >> >>> override. Again, this model may be modified by a lazy consensus >> > >> >>> declaration when the request for a vote is raised, but the >> full-stop >> > >> >>> nature of a negative vote does not change. Under normal (non-lazy >> > >> >>> consensus) conditions, the proposal requires three positive >> votes and >> > >> >>> no negative votes in order to pass; if it fails to garner the >> > >> >>> requisite amount of support, it doesn't. Then the proposer either >> > >> >>> withdraws the proposal or modifies the code and resubmits it, or >> the >> > >> >>> proposal simply languishes as an open issue until someone gets >> around >> > >> >>> to removing it. >> > >> >>> >> > >> >>> We can link to https://www.apache.org/foundation/voting.html. >> > >> >>> >> > >> >>> Regards >> > >> >>> JB >> > >> >>> >> > >> >>> On Tue, Mar 12, 2024 at 2:21 AM Renjie Liu < >> liurenjie2...@gmail.com> wrote: >> > >> >>> > >> > >> >>> > Hi, Daniel: >> > >> >>> > >> > >> >>> > Thanks for this summary. >> > >> >>> > >> > >> >>> > I think one thing missing is that do we need a vote for the >> proposal to be accepted or rejected? If required, what should the voting >> process be? >> > >> >>> > >> > >> >>> > On Tue, Mar 12, 2024 at 9:04 AM Daniel Weeks < >> dwe...@apache.org> wrote: >> > >> >>> >> >> > >> >>> >> Hey everyone, I synced up with JB about the proposal process >> and wanted to see if we could make some initial progress. >> > >> >>> >> >> > >> >>> >> Based on some of the earlier discussions, we want to leverage >> as much of the informal process as possible, but improve discoverability >> and a little structure. This probably means using github for tracking, >> google docs where possible for the early proposal implementation comments, >> and the dev list for discussion threads, awareness and voting. >> > >> >>> >> >> > >> >>> >> That said, I propose we adopt the following: >> > >> >>> >> >> > >> >>> >> 1. A simple issue template for initiating a proposal and >> applying a 'proposal' label to the issue >> > >> >>> >> 2. Use a github search link to document current proposals >> (based on the 'proposal' label) >> > >> >>> >> 3. Continue using google docs for proposals >> documentation/comments (referenced from the github issue) >> > >> >>> >> 4. Continue to create DISCUSS threads on the dev list for >> communication >> > >> >>> >> 4. Backfill current proposals by creating issues for them >> > >> >>> >> >> > >> >>> >> I've created this PR to capture the initial template and docs. >> > >> >>> >> >> > >> >>> >> I think we want to introduce this with as little overhead as >> possible. Please follow up with questions/comments so we can close this >> out. >> > >> >>> >> >> > >> >>> >> Thanks, >> > >> >>> >> Dan >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> On Sun, Mar 10, 2024 at 11:30 PM Jean-Baptiste Onofré < >> j...@nanthrax.net> wrote: >> > >> >>> >>> >> > >> >>> >>> Hi Manu >> > >> >>> >>> >> > >> >>> >>> Yup, it's on my TODO. Thanks for the reminder, I will be >> back on this >> > >> >>> >>> one this week :) >> > >> >>> >>> >> > >> >>> >>> Regards >> > >> >>> >>> JB >> > >> >>> >>> >> > >> >>> >>> On Mon, Mar 11, 2024 at 4:07 AM Manu Zhang < >> owenzhang1...@gmail.com> wrote: >> > >> >>> >>> > >> > >> >>> >>> > Hi JB, >> > >> >>> >>> > >> > >> >>> >>> > Are you still working on this nice proposal? >> > >> >>> >>> > >> > >> >>> >>> > Regards, >> > >> >>> >>> > Manu >> > >> >>> >>> > >> > >> >>> >>> > On Thu, Jan 4, 2024 at 3:35 PM Fokko Driesprong < >> fo...@apache.org> wrote: >> > >> >>> >>> >> >> > >> >>> >>> >> Nice! I fully agree with the abovementioned. I originally >> set up the stalebot for the issues because I noticed that there were many >> issues around old Spark versions that weren't even maintained anymore. I >> feel it is better to either close or take action on an issue. For me, it >> makes sense to extend this to PRs as well. >> > >> >>> >>> >> >> > >> >>> >>> >> Same as Amogh said, always feel free to ping me when >> either a PR or issue lingering and you need some eyes on it. >> > >> >>> >>> >> >> > >> >>> >>> >> Kind regards, >> > >> >>> >>> >> Fokko >> > >> >>> >>> >> >> > >> >>> >>> >> Op do 4 jan 2024 om 07:42 schreef Jean-Baptiste Onofré < >> j...@nanthrax.net>: >> > >> >>> >>> >>> >> > >> >>> >>> >>> Hi >> > >> >>> >>> >>> >> > >> >>> >>> >>> That's also the purpose of the reviewers file: having >> multiple >> > >> >>> >>> >>> reviewers per tag. >> > >> >>> >>> >>> >> > >> >>> >>> >>> Thanks guys for your feedback, I will move forward with >> the PR :) >> > >> >>> >>> >>> >> > >> >>> >>> >>> Regards >> > >> >>> >>> >>> JB >> > >> >>> >>> >>> >> > >> >>> >>> >>> On Thu, Jan 4, 2024 at 6:38 AM Ajantha Bhat < >> ajanthab...@gmail.com> wrote: >> > >> >>> >>> >>> > >> > >> >>> >>> >>> > +1, >> > >> >>> >>> >>> > >> > >> >>> >>> >>> > Some of my PRs have been open for a long time and >> sometimes it doesn't get the attention it requires. >> > >> >>> >>> >>> > Notifying both the reviewer and the author can help >> expedite the review process and facilitate quicker handling of new >> contributions. >> > >> >>> >>> >>> > I think having more than one committer assigned for PR >> can also definitely help in speeding up the process if one of the committer >> is busy or on holiday. >> > >> >>> >>> >>> > >> > >> >>> >>> >>> > But we also need to think on the next steps. What if >> we still don't receive the necessary response even after sending >> notifications? >> > >> >>> >>> >>> > Should we have a slack channel for those PRs to >> conclude by discussing (or some guidelines on how to take it further). >> > >> >>> >>> >>> > >> > >> >>> >>> >>> > We can have a trial run for some days and see how it >> goes. >> > >> >>> >>> >>> > >> > >> >>> >>> >>> > Thanks, >> > >> >>> >>> >>> > Ajantha >> > >> >>> >>> >>> > >> > >> >>> >>> >>> > On Thu, Jan 4, 2024 at 8:19 AM Amogh Jahagirdar < >> am...@tabular.io> wrote: >> > >> >>> >>> >>> >> >> > >> >>> >>> >>> >> +1, I think this is a step in the right direction. >> One other consideration I wanted to bring up was dependabot and if there's >> any unique handling we want to do there because I've noticed that PRs from >> dependabot tend to pile up. I think with the proposal we won't really need >> to do anything unique and just treat it as a normal PR (it would be a build >> label with its own set of reviewers) and we'll get notified the same way. >> > >> >>> >>> >>> >> >> > >> >>> >>> >>> >> I'll also say for reviews (speaking for myself, but I >> think many others probably feel this way as well), always feel free to ping >> on Slack and follow up :) But overall I do like having more of a mechanism. >> > -- Ryan Blue Tabular
