Sometimes I see the “expert list” and “code owners” as gate keepers: a PR should not pass unless they approve it. In theory, it’s a great idea to review PRs. In my experience, it’s quite hard to get a review in less than one week. Sometimes, if I don’t get a review in less than one week, it usually means that I will never get any review on this PR.
I would love to get a review on all of my PRs, but I abandoned this idea long time ago. I defined some guidelines for myself to decide if I must wait for at least one review for a PR or not.
For example, I really dislike touching ceval.c or gcmodule.c without a review since I’m not comfortable in this part of the code, and it’s easy to mess up when touching them. In general, I also prefer to get a review when I add a new public function (at the C level or Python level).
For refactoring-only changes which don’t change the behavior in any way, I just go ahead without review. Development velocity also matters for me: since GitHub doesn’t support “patch series” (multiple chained PR), I like to merge many PRs in a row to get small “atomic” commits. Having to wait for the CI around 30 min to push a single commit is already very long. Pushing 10 small commits takes me 5 hours. Having to wait for a review which takes 1 week for a serie of 10 commits would take 10 weeks instead of 5 hours…
To get reviews, sometimes I ping some developers on IRC, Google Hangout, WhatsApp, IRC, etc. Whatever works 
Sometimes I wrote an email. In my experience, most core developers (if not all) ignore all GitHub notifications.
I didn’t write “review by core developer” on purpose here. In the last 12 months, I got more and more often reviews from contributors who are not core developers. It makes me feel more comfortable to get a review from a complete foreigner to me, than having no review at all!
I dislike pinging core developers too often, so I either try to not propose too many pull requests in parallel, or I skip the review step.
What worked well for me is to work in pair. I did that sometimes with Pablo and Dong-hee for some specific changes. Text chat or video call, whatever works It’s also a way to get more eyes on your code without going through to “formal” review process. Usually, we spent most of the time on investigating a bug or discussing options to solve an issue, rather than writing the code. Reviews can be done later “off-line”