While I understand the intent, it sounds like this should be used as a stepping stone to a trunk-based workflow. PRs are a useful tool for reviewing code, but it can slow up flow if you're constantly having to either find someone to review your PR or work through reviews of open PRs before you can pick up anything new. This is usually offset by the fact that it only happens once a day to once every few days for a given dev (sometimes even less if you're working on a spike), but this format doesn't have that economy of scale.
I think the next step for your team is to look at why you need PRs in your workflow and then see if there are other ways to approach it (e.g. pair/mob programming when you want a second pair of eyes).
Some of our repos have CODEOWNERS configured to groups and we take review SLAs seriously (as every teams should). Also we have pipelines that validate tests, SCA, linting etc so the reviewer gets a heads-up.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
While I understand the intent, it sounds like this should be used as a stepping stone to a trunk-based workflow. PRs are a useful tool for reviewing code, but it can slow up flow if you're constantly having to either find someone to review your PR or work through reviews of open PRs before you can pick up anything new. This is usually offset by the fact that it only happens once a day to once every few days for a given dev (sometimes even less if you're working on a spike), but this format doesn't have that economy of scale.
I think the next step for your team is to look at why you need PRs in your workflow and then see if there are other ways to approach it (e.g. pair/mob programming when you want a second pair of eyes).
Some of our repos have CODEOWNERS configured to groups and we take review SLAs seriously (as every teams should). Also we have pipelines that validate tests, SCA, linting etc so the reviewer gets a heads-up.