costinm
commented
1 year ago IMO the best answer is "yes, but as an external plugin first". If something can be implemented using an existing hook - there is no need to add the risk, complexity and future maintenance to the core project. If a hook is not available - I would rather add a hook than a feature.
Many projects have a design that allows saying yes for almost all features that can be expressed as plugins, either in-tree or as external modules. As a side benefit - with a plugin you don't need to wait for the next release, and as a contributor you can use the feature even if the maintainers say no.
Having to reject feature PRs can be a sign of poor extensibility - in most of the cases the contributor just wants to add a narrow feature that they and maybe few others need, not to become a permanent maintainer for the project or fix things assigned to them to work on. And most likely they won't hang around - but the feature may still be useful. That's what ecosystem and external modules are for.
Saying No In Open Source | howardjohn's blog
As an open source maintainer, I am reviewing roughly 25 ideas per day - whether they are feature requests, design proposals, or pull requests. Inevitably, this leads to saying "No" quite a bit as well. Usually, this is in a softer for like "No, not right now", "No, not in its current form", or "No, unless someone else approves", but the outcome is the same: the change is not accepted, and the emotional impact on the reviewer and contributor is similar.
https://blog.howardjohn.info/posts/saying-no/