Live data from Hacker News

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

news.ycombinator.com

191–200 of 243 posts

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

#191

I usually just say I will consider it for a future release and I move the issue to discussions. And maybe one day I will do the feature, but not cause they told me to. :-)

As a user, I would rather you just say

That being said, I'm also a _lot_ more likely to take no as the answer than the entitled person in OPs post.

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

#192

Earlier quoted context omitted.

Along with the 'no' it may help to point out that they are free to fork the project and add the feature to their own fork, or hire someone to build it for them. That won't stop the most extreme class of complainers, but it'll shave of another few.

Why pointing out something that is a distinguishing feature of open source? I don’t need your permission to fork off the license allow me to, but telling me that I’d like putting a comment like „btw, did you know that 2+2=4“.

Sometimes people get upset about their project being forked. Explicitly offering it as an option assuages any concerns the requester may have about that.

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

#195
A lot of people are suggesting being cordial. For example, "thank you for the request but we cannot handle it at this time". This works for the usual people asking for feature requests but your problem is not so simple.

If you have a persistent requester you can still be professional but far more firm. I would personally say something along the lines of "I have noticed you making a lot of requests. I do not have time to handle them all, but I would be happy to discuss a support contract with you or your company billed at my hourly rate if you need additional support".

Usually demanding money and then ignoring them is enough to either convert them into a customer or get them to buzz off to someone easier to pick on. Since this isn't your case - they won't pay at all - you can be more firm. I don't use github but if it's possible just flat out block them. You could additionally just reaffirm that given the frequency of their requests you would normally service this with some kind of contract and then ignore them.

The key take away is never give someone who exploits you the chance to take advantage of your kindness. It's at these points you need to be firm. Otherwise they will continue to harass you.

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

#196

Hey, this is a situation I'm quite familiar with, both as the PR receiver, and observing PR interactions on other popular github repositories. How you deal with it is very much down to how you want to engage, and your energy levels too. It can be anxiety inducing too because many of us want to avoid confrontation, and saying 'no' can be confrontational, but you need to remember that the other person is not in the sam…

It sounds like OP has a feature requester who is taking advantage of their passive nature. As you stated people want to avoid conflict, and based on what OP wrote it's obvious this person is taking advantage of that.

The only options here are to either ignore them or confront them directly. It helps that asking them for money for all this support they want, and then them refusing, vindicates you and allows you to just flat out ignore them.

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

#197
If it’s something that would actually be helpful and you wouldn’t mind being added tell them you don’t have time but would gladly review the PR.

If it’s not a direction you want to take the project in explain why if you feel like it and let them know that they are free to fork and add support.

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

#198

If you aren’t ready to say no and risk upsetting people, you’ll ruin both your software and mental health I think. 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”.

This is indeed a good strategy, but beware: designing, implementing and documenting a good plugin or extension mechanism is quite some work itself.

If it makes sense for your project to have such a thing, sure, go for it. If it's just a way for you to avoid having to say no... learn to say no instead. :-)

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

#199
I think the Klingon approach would be to challenge the requester to buy something or die (though it was never clear to me if you were then supposed to kill them or if they were expected to perform hari-kari in lieu of purchasing something - both seem like a lot of extra work and overhead)

But if your not Klingon then I think a simple “No” would do.

You could also follow the example of my local Dunkin’ Donuts and A) stare at the requester in silence until they go away B) pretend every question is a grand mystery to be solved and start looking for clues on the surrounding walls, ceiling, and floor C) respond with unrelated nonsense questions like “white wall or black”, “red sauce or marinara”, “does the hulk use sunscreen”, etc.

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

#200

Earlier quoted context omitted.

Along with the 'no' it may help to point out that they are free to fork the project and add the feature to their own fork, or hire someone to build it for them. That won't stop the most extreme class of complainers, but it'll shave of another few.

Why pointing out something that is a distinguishing feature of open source? I don’t need your permission to fork off the license allow me to, but telling me that I’d like putting a comment like „btw, did you know that 2+2=4“.

Because not everyone gets it.
Post reply on HN