Skip to content

chore: Limit open, non draft PRs to 3 for users without write access - #11560

Merged
alamb merged 4 commits into
apache:mainfrom
alamb:limit-open-prs
Oct 15, 2026
Merged

alamb merged 4 commits into
apache:mainfrom
alamb:limit-open-prs

Conversation

@alamb

@alamb alamb commented Oct 14, 2026 •

Copy link
Copy Markdown
Contributor

Which issue does this PR close?

  • N/A.

Rationale for this change

With coding agents, the number of open PRs now far exceeds our review capacity.

The goal of this change is to encourage submitters to help us curate and prepare a small number of high quality PRs, rather than opening many at once, and to help reviewers figure out where to focus their limited time.

DataFusion recently adopted the same limit after discussion apache/datafusion#24413

What changes are included in this PR?

  1. Limit users without write access (non committers), to 3 open, non-draft PRs.

Are these changes tested?

No. This is configuration consumed by ASF Infra and follows the pattern already in use in DataFusion and Airflow. It is not possible to test before merging.

Are there any significant user-facing changes?

No code changes. Contributors without write access will be limited to 3 open, non-draft PRs at a time.

alamb and others added 2 commits October 14, 2026 13:45
Enable `github.pull_requests.creation_cap` in `.asf.yaml` with
`max_open_pull_requests: 3`, following apache/datafusion#25973, and
document the limit in CONTRIBUTING.md.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@alamb alamb changed the title chore: Limit open PRs to 3 for users without write access chore: Limit open, non draft PRs to 3 for users without write access Oct 14, 2026
@alamb
alamb marked this pull request as ready for review October 14, 2026 17:55
@alamb

alamb commented Oct 14, 2026

Copy link
Copy Markdown
Contributor Author

FYI @Jefffrey @sdf-jkl @Rich-T-kid and @etseidl -- let me know if this is a reasonable policy in your mind

@Rich-T-kid Rich-T-kid left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a good idea

+1

@etseidl etseidl left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes please. I feel like I'm drowning sometimes. And I have taken to defensively assigning myself to new issues so someone doesn't jump the gun and implement something prematurely.

That said, it does seem like the generated PRs are generally higher quality now than a few months back. There's just too many right now.

@sdf-jkl sdf-jkl left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That'd be really helpful

@alamb

alamb commented Oct 14, 2026

Copy link
Copy Markdown
Contributor Author

Yes please. I feel like I'm drowning sometimes. And I have taken to defensively assigning myself to new issues so someone doesn't jump the gun and implement something prematurely.

Yes indeed -- I also feel like I am drowning (but for me, all the time!)

@mbutrovich

Copy link
Copy Markdown
Contributor

How does the non-draft limitation help? Does that change what CI runs? Otherwise I could just see people rapid-firing non-draft PRs at the repo and still hammer CI. I guess as a reviewer it makes it easier for me to ignore the ones that aren't ready for review, but it doesn't help the CI situation, I don't think.

@kevinjqliu

Copy link
Copy Markdown

How does the non-draft limitation help? Does that change what CI runs? Otherwise I could just see people rapid-firing non-draft PRs at the repo and still hammer CI. I guess as a reviewer it makes it easier for me to ignore the ones that aren't ready for review, but it doesn't help the CI situation, I don't think.

There are settings to limit CI runs too. i.e. needs approval from someone with write access to run

@kevinjqliu

Copy link
Copy Markdown

The goal of this change is to encourage submitters to help us curate and prepare a small number of high quality PRs, rather than opening many at once, and to help reviewers figure out where to focus their limited time.

I hope this can also encourage folks to review more as well, and not just generate code. There are many different ways to contribute to open source 😄

@alamb

alamb commented Oct 14, 2026

Copy link
Copy Markdown
Contributor Author

How does the non-draft limitation help? Does that change what CI runs? Otherwise I could just see people rapid-firing non-draft PRs at the repo and still hammer CI. I guess as a reviewer it makes it easier for me to ignore the ones that aren't ready for review, but it doesn't help the CI situation, I don't think.

Yes, this PR is designed to help us find what PRs are in need of review, not to reduce the CI load (though maybe it will if it reduces the number of PRs submitted 🤷 )

alamb and others added 2 commits October 14, 2026 15:46

@Jefffrey Jefffrey left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

an unfortunate side effect will be some of our regular contributors may be affected by this (e.g. those from datafusion)

@Jefffrey Jefffrey added the development-process Internal changes; PRs with this label are excluded from changelog label Oct 15, 2026
@alamb

alamb commented Oct 15, 2026

Copy link
Copy Markdown
Contributor Author

an unfortunate side effect will be some of our regular contributors may be affected by this (e.g. those from datafusion)

On the other hand, we can always comment / review PRs while they are draft. I am hoping it will be a good thing for everyone to help focus on only three open PRs at a time.

@alamb
alamb added this pull request to the merge queue Oct 15, 2026
@alamb

alamb commented Oct 15, 2026

Copy link
Copy Markdown
Contributor Author

Thank you everyone -- I will merge this one in and we can see if it makes a difference

@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Oct 15, 2026
@alamb
alamb added this pull request to the merge queue Oct 15, 2026
Merged via the queue into apache:main with commit 786ba61 Oct 15, 2026
34 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

development-process Internal changes; PRs with this label are excluded from changelog

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants