Re: [PROPOSAL] Improvement on our PR flows

Hi, Following this discussion, I'm proposing to cover PRs in stale bot. I created a first proposal PR: https://github.com/apache/iceberg/pull/10134 As we don't have a consensus about automatic reviewers, I didn't include it in the PR. Regards JB On Wed, Jan 3, 2024 at 2:52 PM Jean-Baptiste Ono

Re: [PROPOSAL] Improvement on our PR flows

If you are interested, I have a presentation: how Apache works :) I would be more than happy to join with my "member/director/contributor" hat :) Regards JB On Thu, Apr 4, 2024 at 4:45 PM Brian Olsen wrote: > > That seems like a good start. I do agree there needs to be a better way to > promot

Re: [PROPOSAL] Improvement on our PR flows

That seems like a good start. I do agree there needs to be a better way to promote engagement among other members. Perhaps I can do my next LinkedIn show describing the review process, how Apache works, how to get started, and what NOT to do when submitting a PR. This will likely translate into a

Re: [PROPOSAL] Improvement on our PR flows

Hi Brian, Yeah, I agree with your points. That's why I would like to create a PR as a discussion base (that we can update thanks to everyone's comments). 1. I think we already have a consensus about "stale issue/PR" reminder. 2. The concern is more about "assign/reviewer list". Rethinking this po

Re: [PROPOSAL] Improvement on our PR flows

I think you both (JB and Ryan) have valid points. JB there absolutely is a need to address the scalability issue and we need to come up with a solution. I doubt there’s any disagreement that rising stale issues in the project should be ignored. Ryan’s concern also has merit from a different angle

Re: [PROPOSAL] Improvement on our PR flows

Anyway, I'm preparing a PR to illustrate the proposal. Regards JB On Thu, Apr 4, 2024 at 10:59 AM Ajantha Bhat wrote: > > Additionally, I propose allocating a brief 5-10 minute segment during each > Iceberg community sync. > During this time, attendees can highlight any pull requests needing at

Re: [PROPOSAL] Improvement on our PR flows

Additionally, I propose allocating a brief 5-10 minute segment during each Iceberg community sync. During this time, attendees can highlight any pull requests needing attention. In cases where a pull request has become stagnant due to a lack of reviews, committers can step forward to offer assistan

Re: [PROPOSAL] Improvement on our PR flows

By the way, I worked on a Python program that generate a report containing: - GitHub Issues - Created since more than 6 months - Without assignee - Without activity (comment) since more than 7 days - GitHub PRs - Created since more than 6 months - Without reviewer - With a single review

Re: [PROPOSAL] Improvement on our PR flows

Adding a group of people as reviewers doesn't block others from help and review (and it doesn't change what we do now). I don't see how it's different to today, just having default people reviewing, adding new people. Actually, we clearly have today a bunch of PRs stale just due to lack of reviewer

Re: [PROPOSAL] Improvement on our PR flows

The drawback to the laissez faire approach is that it doesn’t necessarily incentivize people to take action either, and you end up getting the same people generally scrambling to manage the PRs. What about a system that does a basic round robin or random bot assignment of someone from a list to th

Re: [PROPOSAL] Improvement on our PR flows

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 a

Re: [PROPOSAL] Improvement on our PR flows

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

Re: [PROPOSAL] Improvement on our PR flows

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é wrote: > > Hi Dan > > Yes, I saw you merged it, that's great. >

Re: [PROPOSAL] Improvement on our PR flows

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

Re: [PROPOSAL] Improvement on our PR flows

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 web

Re: [PROPOSAL] Improvement on our PR flows

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 1

Re: [PROPOSAL] Improvement on our PR flows

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 re

Re: [PROPOSAL] Improvement on our PR flows

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é wrote: > Hi > > I think a vote would be necessary only if we don't have consensus on a > proposal. If anyone

Re: [PROPOSAL] Improvement on our PR flows

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 i

Re: [PROPOSAL] Improvement on our PR flows

Good point, Renjie I believe we've always followed the code modification vote procedure with 3 PMC votes required and no lazy consensus, but we should probably be explicit about that process. I'll update the docs to reflect that. -Dan On Mon, Mar 11, 2024, 6:23 PM Renjie Liu wrote: > Hi, Dani

Re: [PROPOSAL] Improvement on our PR flows

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 wrote: > Hey everyone, I synced up with JB about the proposal proce

Re: [PROPOSAL] Improvement on our PR flows

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

Re: [PROPOSAL] Improvement on our PR flows

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 wrote: > > Hi JB, > > Are you still working on this nice proposal? > > Regards, > Manu > > On Thu, Jan 4, 2024 at 3:35 PM Fokko Driesprong wrote:

Re: [PROPOSAL] Improvement on our PR flows

Hi JB, Are you still working on this nice proposal? Regards, Manu On Thu, Jan 4, 2024 at 3:35 PM Fokko Driesprong 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 th

Re: [PROPOSAL] Improvement on our PR flows

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

Re: [PROPOSAL] Improvement on our PR flows

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 wrote: > > +1, > > Some of my PRs have been open for a long time and sometimes it doesn'

Re: [PROPOSAL] Improvement on our PR flows

+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

Re: [PROPOSAL] Improvement on our PR flows

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

Re: [PROPOSAL] Improvement on our PR flows

+1 My team did an initial manual review of the Trino backlog and we found a lot of value there. 1) We found 3 PRs that were ready for merge but accidentally missed the boat for deployment. 2) We revived a few older PRs where there was actual interest from the developers. 3) With the PR count down

Re: [PROPOSAL] Improvement on our PR flows

+1. In the same spirit, our ISSUE flows can also be improved. There are over 900 open issues without proper tags, fix versions, etc, and many of them are no longer valid. This can be a separate proposal though. On Thu, Jan 4, 2024 at 9:18 AM John Zhuge wrote: > +1 good idea > > On Wed, Jan 3, 20

Re: [PROPOSAL] Improvement on our PR flows

+1 good idea On Wed, Jan 3, 2024 at 5:15 PM Renjie Liu wrote: > +1 for this enhancement. > > On Thu, Jan 4, 2024 at 2:19 AM Jack Ye wrote: > >> +1, sounds like a good idea to clean up stale PRs. >> >> -Jack >> >> On Wed, Jan 3, 2024 at 9:52 AM Russell Spitzer >> wrote: >> >>> I definitely need

Re: [PROPOSAL] Improvement on our PR flows

+1 for this enhancement. On Thu, Jan 4, 2024 at 2:19 AM Jack Ye wrote: > +1, sounds like a good idea to clean up stale PRs. > > -Jack > > On Wed, Jan 3, 2024 at 9:52 AM Russell Spitzer > wrote: > >> I definitely need something to keep emailing me, so I support this. >> >> On Wed, Jan 3, 2024 at

Re: [PROPOSAL] Improvement on our PR flows

+1, sounds like a good idea to clean up stale PRs. -Jack On Wed, Jan 3, 2024 at 9:52 AM Russell Spitzer wrote: > I definitely need something to keep emailing me, so I support this. > > On Wed, Jan 3, 2024 at 7:52 AM Jean-Baptiste Onofré > wrote: > >> Hi guys, >> >> We have several examples whe

Re: [PROPOSAL] Improvement on our PR flows

I definitely need something to keep emailing me, so I support this. On Wed, Jan 3, 2024 at 7:52 AM Jean-Baptiste Onofré wrote: > Hi guys, > > We have several examples where we have some kind of "stale" PRs, > either because we are waiting for a review, or we are waiting for > changes from the c

[PROPOSAL] Improvement on our PR flows

Hi guys, We have several examples where we have some kind of "stale" PRs, either because we are waiting for a review, or we are waiting for changes from the contributor. We are already using two jobs around issues/PRs: - labeler to label PRs depending of the Iceberg modules change scope - stale