[DISCUSSION] PR Review Process / States / "How to find the PRs in the list that need review"

[alamb]

This is related to the broader discussion about organizing DataFusion's growth:

• [Meta-EPIC] Organizing DataFusion's Growth #21036

As the number of open PRs grows, it is getting harder to quickly see which PRs need attention and how best to help.

For me personally, I struggle wiht:

• If I have time to review PRs, it is not obvious which open PRs are waiting on review and which are waiting to incorporate feedback
• If I have time to merge PRs, it is not obvious which already approved PRs are waiting for the 24 hour period .

For example, I personally use these two searches to find waiting PRs

• DF Approved PRs - currently has 21 open
• DF Review PRs - currently has 186 open

I think the core issue is that the current way to find PRs mixes together many different states, which makes it harder to triage efficiently

Also, there is currently no documented "review priority".

Describe the solution you'd like

I would like a clearer and more explicit way to find PRs that need community attention.

I think at the core we probably need some sort of triage process and "workflow" for PR review / merge attention. I am acutely aware that we have very little extra capacity for such a process with the existing committers, but I do wonder if having it might attract others who can help the reviews along

Describe alternatives you've considered

For example, a PR priority definition might look like (not saying this is the right one, it is just a strawman)

• Regression Bugs (what used to work doesn't anymore)
• Bugs
• Performance Improvements
• New Features

For example, a PR review flow might look like this

flowchart LR
      A[Needs Initial Review] --> B[Feedback Received]
      B --> C[Feedback Addressed]
      C --> B
      C --> D[Approved, waiting]
      D --> E[Approved Ready to Merge]

Loading

Additional context

[alamb]

I think @neilconway may have some thoughts on this one too

[adp2201]

My recommendation would be to document the PR flow first, and only add labels later if there is still a real gap.

A lightweight documented flow like this would already help a lot:

• Needs initial review
• Waiting on author
• Ready for re-review
• Approved, waiting 24h
• Ready to merge

By “define the corresponding queries / saved searches”, I mean mapping each of those states to a GitHub PR search so people can quickly see the current list for that state without adding more process immediately.

For example:

• Needs initial review → open, non-draft PRs that are not yet approved
• Waiting on author → PRs with requested changes / unresolved review feedback
• Ready for re-review → PRs updated after review feedback
• Approved, waiting 24h → approved PRs that are still inside the waiting window
• Ready to merge → approved PRs past the waiting window

I’d try that first using GitHub’s existing signals before adding labels. Labels can help, but they also create maintenance overhead, and stale labels can make things less clear rather than more clear.

So my preference would be:

1. document the states
2. define the matching queries / saved searches
3. add labels only if there is a state GitHub cannot represent clearly enough on its own