Not enough reviewers for PRs: several contributions are blocked

[Waxime64]

Hi team,

There currently seems to be a shortage of available reviewers, which leaves multiple pull requests completed but waiting for human review. This slows down progress and discourages external contributors.

Concrete example:
• PR pending review for more of 4 days: #5644

I’d love to help move Codex-CLI forward and I’m ready to contribute more. However, if PRs remain blocked due to missing reviews, it becomes hard for people outside OpenAI to help the project progress efficiently.

[Waxime64]

And yes all test pass

[etraut-openai]

Thanks for your interest in codex — and for your contributions.

Yes, we have limited bandwidth on the codex team for reviewing community PRs. We're working on some refactors to make the code base more maintainable in the long run. We're also trying to maintain a high code quality bar, and thorough code reviews are important in this regard.

It helps if you can keep PRs small and fixes surgical and targeted. The PR you submitted is large and more involved than I would expect for the bug it is attempting to fix. If you're able to create a more targeted fix, that will increase the likelihood that it will get reviewed in a timely manner.

[Waxime64]

Thanks for your answer
I can only talk for me. But in my case, for implement image in WSL environnement we didn't have choose to not use CTRL + V becose CTRL + V with base64 image (Screenshoot) is blocked by WSL. For not impact all OS, I have to detect if we are in WSL change shorcut for CTRL + ALT + V and retreive de clipboard from windows and transfer it into WSL (best and clean way is in powershell).

And for good modification, I have to update documentation under ? for write CTRL + ALT + V only when we are under WSL

Claude-Cli have exactly same problem too. It's a limitation of WSL

[Waxime64]

I simplify my code and remove new comment where not important
only the diff of codex-rs/tui/src/clipboard_paste.rs is removing everything and add it. kdiff3 only see small update

[imajes]

@etraut-openai -- thanks for commenting here. Can I ask also what the policy is within your team regarding high quality commit messages and PR descriptions?

I appreciate you want to maintain a high bar, but it feels like there are significant changes made by internal devs which go from PR -> merge super quickly, without much in the way of documentation for the change. I appreciate y'all may have an internal linear, jira or similar -- but it can be tough to follow, especially around the exec + sandbox stuff (which is changing quite a bit right now, and has bugs).

It's also tricky to know how best to support - I've also made PRs that went ignored. I understand if y'all are doing something else in parallel or have other plans, but it's a bit tough!

anyhow, thank you for dropping by and actually answering here-- it's appreciated.

[imajes]

100% !! totally makes sense, and I completely agree where you're at.

So, i'm curious -- what's the best way to bring something to a maintainer's attention that you want to work on? Or, what's the best way to bring immediate/usable feedback? For example, I have found that streamable_exec doesn't work anymore (it now prompts for escalation for every single exec)

I haven't had time to bisect to figure out the exact commit it shows up in, but like - filing issues etc -- is that even worth it? because there are already > 1.1K of 'em... i wouldn't want to have to triage all that!

[etraut-openai]

what's the best way to bring something to a maintainer's attention that you want to work on? Or, what's the best way to bring immediate/usable feedback?

Post to the issue thread. I can't guarantee that you'll get an immediate response, but we will see it.

[imajes]

@etraut-openai is there any way to not automatically lock PRs on merge? because like a lot of stuff would best be attached as feedback to a PR (e.g #5920)

[etraut-openai]

I don't think it's a good idea to post comments to merged PRs. Once a PR is merged, it is considered complete. If you spot a bug in a PR that has been merged, please open a new bug report in the issue tracker.

[lostmygithubaccount]

I don't think it's a good idea to post comments to merged PRs. Once a PR is merged, it is considered complete. If you spot a bug in a PR that has been merged, please open a new bug report in the issue tracker.

I disagree because comments/feedback on PRs after merged by default notify the people involved in the PR, who are typically the right people to address follow ups. Thus is seems much more likely they will take action vs trying to get their attention with an issue. Also, it is trivial in GitHub to create an issue from a PR comment and that provides much better lineage than if the PR is immediately locked. Though I certianly understand locking them to avoid spam, perhaps it could be after a period of time instead of right after merge?