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

If they won’t pay and you aren’t interested in building the feature I would bluntly state that.

“PR welcome but I will not be writing this personally. Closing for now”

"No" is a full sentence. You do not owe anyone an explanation beyond "I do not feel like working on this feature".

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 same mindset as you.

Options.

You are perfectly entitled to completely ignore the request. Don't comment any more, just stay silent for ages and ages. The issue can languish for years. If you want you can close it off after a long time. Even then you can close it without comment, or say you don't plan on implementing anything here. You may not like this option as it feels like you're running away, but I'll also say that it's something that happens across many repos for many years, both intentionally and unintentionally.

You can nip the issue (haha... get it?) in the bud. Be straightforward and say that you are not planning on implementing, maintaining and supporting that feature. Your time and energy are limited, and you don't feel it's a feature that you want added to your codebase. Close the issue with the comment. The reaction may be varied but it is important that you stick to this statement and not entertain further commenting, because each new line can sometimes be an 'in' to argue more.

You can take the most pacifist route which is to keep explaining, and refuting, that you don't want to implement the feature. Most people are quite receptive to it and will actually understand, but it's also possible you've encountered someone who is not able to understand your intention. This can be mentally draining as you're speaking to someone of a different mindset, who views you in a certain way, and nothing can convince you otherwise.

But at no point is there any need to insult anyone. Keep in mind it's your codebase, and you will be maintaining the feature going forward. If you do not respect your time, nobody will. Please respect your time OP.

Say "no", block said user. If he needs the software to do things that it currently doesn't he can either fork the project or use something else altogether.

Just reply something like "This feature does not interest me, but patches are welcome!" and leave it at that.

This does not mean you actually will merge any PR for said future, should they ever materialize.

Ask for a six figure donation

> The main reason is, the requester behaves like I am hired to customise the software for him. And I should keep working until he is satisfied.

Just tell him your fee and that you’ll start for a 50% deposit.

You can simply close the ticket without saying anything, you are not required to do anything if you don't feel like it, and you should not feel bad about it.

yea you can say fuck off

well politically correct answer is to fork off

they should fork it instead haha

If it's public facing I would suggest that you keep it in context and PR friendly and say something like:

"I am declining this as it is not fitting with the direction of the project and other users' requirements. You are free to fork it and maintain your own version"

If you don't see that the feature would fit your vision of the codebase then just tell them that.

If you think it is a useful feature tell him that you currently don't have time to implement it yourself but a PR is welcome.

Often people only want that there issue is tracked, so to avoid conflict and just do nothing just tell them that it goes into the backlog of future features to be considered ;)

Close issue. "Won't fix"

Might as well ban some commenter from your project (not sure how Github manages this)

A lot of feature requests are done to gain clout anyway

This sounds like a problem you will face many times in the future and therefore you may benefit from finding a solution that will solve for both this request and all similar future requests. For example, instead of writing any customised response, you could write a blog post / make a webpage that explains your approach to these types of request and then simply link to it in a reply. Then every time this comes up you can simply paste in “Thank you for your request. Please see [URL]”.

I find doing this type of thing (creating nice canned responses, creating reusable answers) nearly always pays off in the medium and long term and find that it’s much easier to put the effort into a response knowing that you’ll get long lived value from it vs it just being useful for one person.

Similarly, I often find others have done similar and if their thoughts align with mine I don’t need to write the answer myself but instead can refer to someone else’s blog post etc.

Draw up a quote ?

I mean it’s a bit glib but I’m serious.

This presumes you want to be paid. Many don’t because it means it’s not fun anymore. I’m in that camp.

Huge sense of entitlement showing up on project forums is inevitable. I think it is okay to be open and blunt (and civil) when responding to such posts.

I had ended up codifying [1] my stance around this to a contrib document to quickly link to annoying issues when closing them. Saves the headache of having to write fresh explanations.

[1] - https://github.com/knadh/listmonk/blob/master/CONTRIBUTING.m...

I think you have those options on how to react to a feature request:

  1. Great idea, I/we will implement it  
  2. Great idea, Pull Request welcome!  
  3. Out of scope, won't be implemented (even if a pull-request is submitted), because ..., /close  
  4. Out of scope, (no explanation) /close

If you're the single maintainer of a project, it's easy. Write one sentence and just close the issue or pull request.

If you're a team maintaining a project, you need to agree with the team on that, obviously.

But keep in mind: random Github users are just random Giuthub users, random people. Treat them with the respect they deserve. If they don't deserve a lot, just close their issues.

There are people like that. They will keep riding you for as long as you keep responding in a polite and reasonable manner.

The tactic is to add progressively larger delays to each response, while make them shorter at the same time. Start with a delay of a couple of days and progress to weeks. This works and it's very effective in discouraging this sort of behavior.

The same works with for new tickets, but you can just close them after a week. Optionally add something like "Dully noted, thanks".

There's no reason to be upset :) I understand it's offensive, but trying to be neutral/detached, and "professional", is IMO the best approach (also, for one's health).

You don't have resources for that (I presume), and clarify this is (IMO) the appropriate, neutral, answer; that's all.

There is also another sneaky approach. You can add that you're open to commercial support, and to contact you in private for the details. I think this is also understandable, but better be careful. This will surely put things in perspective to the user.

(background: I'm a maintaner myself, although I've never dealt with abusive users; I did make it very explicit though, when I didn't have resources, and users were always understanding).

Would you accept it if they did offer a (high quality, fitting the project style etc.) PR?

If so, something I see a lot which I quite like is along those lines - not something the maintainers are interested in (or whatever) so unlikely to be implemented, however high quality PRs will be considered.

Probably you're right, and they'll never offer one. But if you'd genuinely consider and perhaps merge one if they did, I think this is a good outcome for everybody.

(Plus then you can leave the issue open which can be appeasing - and catch others requesting the same - just lock it if necessary as nothing further to discuss without a PR which can be discussed in its own comments.)

Your point of view is very clear: it's not a feature you're interested in. But it doesn't mean that it's not a good feature for the person who has opened the issue.

Instead of convincing them that it's a bad feature or talking about why it's uninteresting to you, just point them to a CONTRIBUTING.md and stop engaging with them after that. If they're actually serious about the feature, they can implement it in their own fork (which then you can request as a PR if you want it in your repo).

My two cents:

I'm not really interested in adding this. We can discuss the feature further if you're willing to fund it, or to implement and maintain it yourself for the foreseeable future. Otherwise I'm considering the issue closed.

"This feature isn't in my personal to-do list. Remember that this is free work on my part, not a contract between us two. If you wish to have this feature implemented anyway, my basic quote is X dollars per hour, and you will have to pay at least 100 hours upfront."

If they don't stop bothering you after that, just block them.