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?

I once made a PR to a project I use a lot at work. The PR was about the documentation of the project, so no change to any feature, no new thing, just an improved version of the tutorial... Or so I thought. The maintainers refused my PR. My first instinct was to be upset about it, but then I thought "this might be a natural reaction because they said 'no', but maybe, just maybe I can avoid acting like a kid and use my brain". So I re-read their reply: it contained a valid reason and provided me with a good solution to my problem, I thanked them and moved on. They were just right to refuse my PR.