There is also the option of allowing more people to become committers.
Committers are given the authority to, well,
• commit,
• review and accept PRs.
◦ Ask for changes to ensure that the code matches an agreed standard.
(You have coding standard : That you have published online / in a wiki - that committers have write rights to - to change on the fly - so it never gets old and stays current.)
As you allow more people to accept PRs - the community gets quicker results (for changes in the code) and individuals get quicker feedback / success for their submissions.
Thus, they get more enthusiastic about helping out... you get more PRs.
After an initial learning curve, you find some that are consistently delivering PRs that don't require changes. They meet the agreed standards, they include a test, automatically, for their new work - or they detail in their PR how the XXX, existing test, proves their change...
These people, you invite to become committers, too.
People will come and go... but you need to lower the barriers that stand in the way of people who want to help, being able to do so.
I worked as the Patch Manager for Apache SVN for 4 years and it was project that overthrew CVS and was the default until git came to prominence and it was without doubt a successful project with a considerable amount of work being done by many, for free!