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 point, actually, we can address this with the 1: if we have reminder in stale PR, then someone can engage. So, I propose to start with 1, and experiment/see how it works. Regards JB On Thu, Apr 4, 2024 at 1:26 PM Brian Olsen <bitsondata...@gmail.com> wrote: > > 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 that could lead to > similar outcomes (stale PRs) with the current proposed solution, as ownership > while establishing and growing responsibility, could lead to fiefdoms. > > There’s clearly some support for a solution and so submitting the proposal as > a more tangible PR is a good idea. At that point we can further revise this > solution to account for both concerns. This also would be a good one to > discuss in realtime at a community sync. > > Thanks for the edited here! > > Bits > > On Thu, Apr 4, 2024 at 4:12 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: >> >> Anyway, I'm preparing a PR to illustrate the proposal. >> >> Regards >> JB >> >> On Thu, Apr 4, 2024 at 10:59 AM Ajantha Bhat <ajanthab...@gmail.com> 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 >> > attention. >> > In cases where a pull request has become stagnant due to a lack of >> > reviews, committers can step forward to offer assistance by conducting >> > reviews and aiding in its resolution. >> > >> > - Ajantha >> > >> > On Wed, Mar 27, 2024 at 12:06 PM Jean-Baptiste Onofré <j...@nanthrax.net> >> > wrote: >> >> >> >> 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 reviewer >> >> - Without activity (comment, etc) since more than 7 days >> >> >> >> The report is a HTML page. I will send it on this thread today or >> >> tomorrow for review. >> >> >> >> For now, I only generate the HTML (locally on the machine), but it >> >> would be possible to publish on website or automatically (cron) send >> >> on the dev mailing list. >> >> >> >> Regards >> >> JB >> >> >> >> On Wed, Mar 27, 2024 at 6:57 AM Jean-Baptiste Onofré <j...@nanthrax.net> >> >> wrote: >> >> > >> >> > 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 reviewers. From a community standard, I'm also concerned that a lot >> >> > of PR is waiting for review from the same people: that is a concern >> >> > for community engagement. If we have 3 persons that should >> >> > review/approve 90% of the PRs, it doesn't scale, it doesn't engage the >> >> > community, other committers/PMC members might be feeling "untrusted". >> >> > >> >> > So the idea is actually to grow the community: the group of reviewers >> >> > can invite other people to review (having default reviewers on some >> >> > modules doesn't block adding others). We have several examples of >> >> > Apache projects where it works fine (Apache Beam is an example, we >> >> > increased the community engagement thanks to feedback from reviewer >> >> > pretty quickly instead of stale for a while and contributors give up >> >> > due to no response). >> >> > >> >> > Anyway, I propose to update my proposal this way: >> >> > 1. I update the stale PR periodical reminder (every week) >> >> > 2. I don't add reviewers yml, but if a PR doesn't have reviewer after >> >> > a week, I send a report on the dev mailing list listing all stale and >> >> > no review started PRs) >> >> > >> >> > Regards >> >> > JB >> >> > >> >> > On Tue, Mar 26, 2024 at 5:03 PM Ryan Blue <b...@tabular.io> wrote: >> >> > > >> >> > > 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
