The obvious solution for owners of such projects is to grant more people commit access so more people can handle outstanding PR's. A single person being respon

The obvious solution for owners of such projects is to grant more people commit access so more people can handle outstanding PR's. A single person being responsible for all pull requests doesn't scale. But the issue is that owners don't like giving up that much control, because it can lead to the project being taken in a direction they didn't originally intend. This is an issue for any open-source project, which is why the biggest projects tend to have a structure where there is a dictator, a hierarchy of core contributors, and everyone else should stick to mailing lists or pull requests to contribute code. But for small projects it's difficult because it's tough to make that kind of hierarchy work on GitHub. I'm starting to think there needs to be a boilerplate "Contribution Guidelines for Small Open Source Projects" meta-guideline that small Open Source projects (on the size of things like gems or small utilities) can adopt, similar to how projects can adopt SemVer or a particular OSS license. Some simple tenants of such a guideline system (or basically, an example thereof:) 1) Contributions to this Open Source project shall adhere to this projects MANIFESTO.md, which shall define the goals of the project, its scope, what it aspires to be, etc. 2) The owner of this open source project shall grant commit access (promoting them to "Core Contributors") to developers who show a consistent drive to make enhancements and fixes that fall within this well-defined manifesto. 3) Only the owner shall make changes to the manifesto. Changes to a project's manifesto should require a fork of the project. Manifestos can be designed by consensus but it should ultimately be up to the owner to commit the change. 4) Core contributors should be able to merge other developer's pull requests, and even grant commit access accordingly. If any commits get merged which fall outside of the manifesto's guidelines, the commits can be rolled back by the owner, or the core contributor can make the case for changing the manifesto, or they should fork the project to keep the commit. I don't really have the clout to be able to develop such a meta-guideline (I'm not active in any OSS projects), but I think it would be really cool if someone would.