I’m not sure I understand your issue, so please forgive me if my answer isn't as helpful as I wish
I think all the tooling like Slack or Teams could help with the flow, but will not solve if the basics are not in place. So let’s review the basic problems (as I understood them)
The part which confuses me is:
No way to know when a pull request is ready to be reviewed.
It seems to be a bottleneck.
Both in my current and previous team, we had a simple rule: if a PR is opened, that means it’s ready for review and test must pass. If you’re still working on it, add a WIP: prefix in the PR title.
It really makes it easy to see what’s ready to review or not. Code review is a shared responsibility between the submitter and the reviewers. The submitter needs to make sure the PR provides good review context, which implies the basic «is it ready for review» info, but also all the context required to help the reviewer focus on the most relevant parts. And the reviewers have the responsibility to give quick (for some definition of quick), constructive feedback.
There's no way for PR author to know when their pull request is ready to be merged Same thing: a simple rule like 1 approval, or 2 approvals should be enough here. (Actually I haven’t used Github in a little while, but that’s something we enforce on Gitlab)
We rarely use GitHub's built-in "assignees" and "reviewers" features because usually, it's more than one person who can review a pull request. (...) No clear picture of all currently open PRs from my team. We structure code as one big monorepo with multiple teams working on separate code paths. This makes using GitHub's pull requests page almost impossible.
Maybe I missed the obvious, but wouldn’t using the reviewers feature solve the issue? It’s build for that ;) If there’s only one or two reviewers who would be relevant for a PR review, then it’s very easy for the submitter to set them (and usually, as a fallback, tools like git blame give a good idea of the good potential reviewers who already worked on the codebase which has been modified) If people know that they should focus their review on the PR on which they are assigned, it makes the review process much easier. It’s very little effort for the PR submitter, and makes it so much easier for the reviewers. And suddenly Gtihub’s github.com/pulls/review-requested becomes very useful ;)