Ask HN: How to say no to a GitHub issue feature request?

A workaround to simply saying “no” might be to make extension points or plugin functionality and then lots of requests can be closed with “this is a good idea for an extension but not suitable for the core application, at least not at the current time”.

Many requests are probably simply outside the scope of the project, better done in some other way than the requestor wants.

Some others will be legitimate ideas that would be fine but you just don't have the time to do it. For those I just just mark them as as an enhancement and leave the issue open. I basically say "I agree, this would be a good addition" and the issue can sit there open and tagged as "enhancement" forever for all I care. Maybe someday I'll do it, maybe some day someone else will, or maybe eventually the idea will be obsoleted by something else, or not, I don't care.

The more difficult thing is rejecting a bad implimentation of an agreed good idea.

It's relatively easy to decide what jobs your project should and should not try to do, and then say for each issue whether it falls inside or outside that border. It's a little harder to say "This is a fine idea but I can't do it, and I also reject your attempt to do it."

Even that is still doable though. You just say what the problem is and they can address it (or argue their position and successfully change your mind on some point by simply being right about it), or not.

I think the biggest thing, 2 things, is 1 just know what you're about onnyour end, have a clear idea what your thing is for and what it's scope is, so you always know how to tell the invalid ideas from the valid. and 2 be open to discussion regardless. Maybe an idea that you initially thought was invalid, is actually valid. Allow for the possibility that the requestor is a better engineer than yourself, and has ideas that would actually be good to adopt. They still have to successfully argue their position, and if they can't then they can't, but just treating it as a conversation where you and the user are both hashing it out and figuring something out together makes the eventual denial not feel as bad. Or not feel bad at all since if your vision is clear and your reason for denying is valid, you will have conferred that understanding to them and they'll even agree with you in the end.

And for the few that simply don't play nice, by doing your part, you no longer have to feel the slightest guilt or pressure simply ignoring them by that point. You don't have to get sucked into any stressful fights, you don't have to take any of their attempts to criticize your character to heart. If you explained your reasoning, and you allowed them to dazzle you with better other reasoning, and they failed to present any convincing other reasoning, then your hands and your conscience are clean. F'em. Mark the issue as invalid with a summary of what makes it invalid for future reference, and close it. Close all future duplicates with a link to this one unless and until someone provides new info or reasoning.

"I'm glad you are interested in the software I wrote! Please keep in mind that I wrote it for my own personal needs, and decided to share it with others. I may add features I find helpful, but adding features I don't believe should go in (even if they are really helpful to others, like you) will bite me in the future, because all code makes the codebase more complex, and I alone will have to support it all."