Proposal: Limiting Open PRs

[matthewmcneely]

To keep pace with a surge in (often AI-generated) PRs across our maintained repos, we propose capping open PRs at three per contributor, per repo. Draft PRs don't count, existing open PRs are grandfathered in, but new PRs are blocked until you're back under the limit. This applies across all active repos.

For years, the Dgraph team has prided itself on shipping quality code. Pull Requests go through a deliberate review process that takes significant time, not just for correctness, but also for factors like backward compatibility issues, performance implications and more. Like other open source teams, the Dgraph team is struggling to keep up with the number of PRs (many of them AI-generated) that it is currently receiving across the dozen or so repos that we actively maintain.

To help focus our attention on reviewing and merging accepted PRs, we are proposing imposing a limit to the number of PRs contributors can have open at any given time. We are proposing that number shall be three. Draft PRs do not count against this limit. Existing open PRs will not altered, but you will be prevented from opening new PRs until you're under the limit. We plan to implement this policy across all of our active repos. The limits apply per-repo.

Making this restriction is not an easy choice. Hundreds of PRs from contributors have made Dgraph one of the most respected open source graph databases available. However, the attention we strive to give to contributions is currently being outpaced by generative AI.

[rahst12]

To set expectations for the community, how many people on the Dgraph Team are available to execute the PR process? Even with a limit of 3 PRs per community member, how many PRs can the Dgraph Team concurrently review, evaluate, and provide feedback on?

Another thought - establishing a limit of PRs may cause contributors to generate larger PRs to fit all their work into a single PR, where in the past they would have otherwise submitted multiple PRs. The size of a PR is a developer preference, but the team I work with leans toward smaller PRs for easier review and targeted changes.

Lastly, giving the community greater transparency into the PR queue, notably what is currently being worked and what is next, may support a healthier selection of PRs submitted by the community and increase patience while PRs are prioritized. This, in tandem with understanding the number of concurrent PRs that can be worked, should organically give the Dgraph team high-quality PRs, as higher-quality PRs would presumable make it up the priority list faster and progress down the PR could can be seen.

As always - very much appreciate the Dgraph system and people behind it! Thanks!