Four years ago I got a PR on a small side-project. It was a nice new feature, although it wasn’t exactly the scope of the project. At that time I thought it wou

Four years ago I got a PR on a small side-project. It was a nice new feature, although it wasn’t exactly the scope of the project. At that time I thought it would be better to accept the PR since the contributor put some efforts into it, and it would have been rude (or so I thought) to say no. Four years later, I’d say 50% of the burden on that project is due to the feature that PR introduced. I often think about that time, and during these four years I’ve learnt to say no to PRs, mostly after seeing more-experienced open-source leaders doing so. The key aspect is maintainance: contributors come with a feature, they add it to your project, and then the maintenance burden is on you forever. Too much maintainance means you burn out, and the project is dead. It’s important to keep that in mind when deciding to accept or refuse a PR. To avoid misunderstandings and angry people, you should be as neutral as possible: is it a good addition on the long terme? How much maintenance cost does it add? Will it make the project easier/harder to evolve?