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

The best thing to do is to decide where your boundaries are, and then tell them.

I was in your position many times. I was so frustrated to feel like the other person was entitled to my time. Then I had to fight my urges to tell them to fuck off, wasting even more time and energy in the process. Even if I replied, it wasn’t helpful to anybody if I was being polite but passive-aggressive.

Then I realized that it was a huge misunderstanding. How can people know what my limits are if I don’t tell them? We don’t all share the same sensibilities and background. Instead of getting upset, it’s possible to tell people and move on. 99% of the time people understand and respect that.

Since then, I adopt the following classification:

1. Is the feature interesting to me? Let them know

2. If not, would I accept a PR for it? Let them know, with also some criteria for inclusion. No half-baked attempts please.

That’s it.

One surprising thing I discovered is that I wasn’t entirely clear where my limits were. Going through that process over and over again helped me figure that out. And become better at communicating clearly.

And if 2. is “no” then let them know why not, but there is no need to “debate” it further either.

Sometimes it’s very important NOT to add features to a project. In fact I would argue that this is one of the strengths of OSS projects compared to “enterprise software”.

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.

Exactly.

Each software has a shape that makes sense, in the eye of the creator. That shape might change but it has to stay internally consistent somehow.

Unlike companies, we don’t have to eternally grow the software to satisfy every customer and stay releavant. Projects come and go and this is a good thing.

“This feature is a bit out of scope”(if applicable). “Our team, aka me, has limited time for this project, and I just don’t have the bandwidth. I can answer questions or possibly collaborate if you’d like to have a go at the code yourself though.”

“This is a personal/internal use project made available to the community as is, and adding features outside of what I need for my own company is not a priority. You’re welcome to submit a PR if you do get the feature implemented yourself though.”

(If applicable) “It does seem useful so I’ll leave this issue open in case someone else wants to implement it, but I don’t currently have a need for it”.

“If this feature is very critical, we can talk about some paid support options, but otherwise, free software is largely created by companies and individuals for their own needs, and we don’t have time for every feature request”

There’s another consequence to consider as well: even if a PR does materialize externally, do you want to sign up to maintain it in your codebase?

Exactly. Pull requests are not a golden ticket here – they still take (a lot of) time to review and maintain.

In my experience pull requests, particularly for (larger) features, can be net negative contributions. If the pull request is done poorly they can easily take more time to review, fix and maintain than it would have taken the maintainer to implement the feature in the first place.

Hi, sorry but this is simply not something I’m interested in implementing.

Further, please remember that GitHub maintainers do this for free, on their own time.

Thanks!

—

Anything more than that, block and move on. I’ve been on GH for 10 years or so and it’s gotten really bad in the last few regarding pushy dickheads like this.

You owe nothing to them, and if they can’t behave within the OSS ecosystem then they’re going to get blocked. Plain and simple.

In the past, I’ve simply responded to drive-by PRs with “No thank you :)” and closed them. Not common but sometimes people do stuff that makes no sense and you just can’t really say anything other than that.

As someone who makes lots of merge requests, please don’t add the further statement. In my experience while it’s well intentioned, it (understandably) frustrates contributors because it’s making an assumption that they aren’t valuing your time, which you don’t know.

Just my 2¢, at the end of the day do what feels best for you, but you may drive away some contributors.

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.

> simply paste in “Thank you for your request. Please see [URL]”.

I think this can make people feel like you don’t understand them and maybe make them angry. It feels like an automatic response you would post when you haven’t even read the request. I think you should at least clearly say that you don’t want the requested feature in the response, then you can link to the page.

> That sounds like a them problem.

Yes and it’s not nice to give people problems. It can even come back to you if they don’t feel like they got a clear response and continue to bother you.

I like to communicate in ways that are clear, honest and complete because that way people get the information they want and we can understand each other. I think the world would be a better place if everyone did that and therefore it’s what I recommend people to do.

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.

You can just politely say no. That’s it, don’t feel obligated to do anything else (and for that matter, even this is optional).

I don’t recommend you say f off or be hostile, it’s not worth the trouble, be gracious and kind, but don’t be afraid to be firm and establish your boundaries.

If he keeps bugging you, simply ignore him or block him if needed. There are lots of entitled people on the internet, it’s up to you whether you ignore them, get upset or comply with their unreasonable demands.

Open source doesn’t mean free work, it also doesn’t mean you need to review other people’s PRs, and it doesn’t mean you need to merge someone’s pull request with an amazing feature.

Everything is optional and at any time you can say no.

> You can just politely say no.

To emphasize even more, you do not need to explain yourself at all, in any way. You may want provide your reasons / rationale, but you don’t have to (see other comments stating that as well).

> To emphasize even more, you do not need to explain yourself at all, in any way.

I would suggest that you should not explain yourself in any way. Chances are they would just view that as an open door to argue their point and they will try to use your words against you.

A polite no is still a no. Some people just need time to realize that.

Absolutely.

Another answer I don’t recommend is “PR welcome”. Accepting some random person’s feature then getting it merged comes with lots of costs, from the one time cost of code reviews to the ongoing cost of maintaining the feature.

Only say “PR welcome” if it is really welcome.

When I started with open source, I was hyped to get any feedback, bug reports, feature requests, and such, and I always tried to do my best to address these.

After 10+ years of maintaining popular projects (e.g., https://nodemailer.com/) and going through thousands of tickets in the process, I mostly ignore the incoming issues and requests now. Is it a clear bug I didn’t know about – sure, I’ll take it up as soon as possible. Anything else – I’ll ignore it, don’t even respond anything, and the stalebot will close that ticket in 30 days unless something additional comes up (usually it does not).

No one pays me for it, so I find my responsibilities to end at the point where the software is maintained and works on every supported platform. If someone does not like that, they can always fork the project.

Is it a product made by employees of EmailEngine or how does it work ?

Intuitively I would find it super rude if commercial companies just ignore or send people away for open-source tooling that is directly used for their commercial product.

Like when there are Google APIs Python Client bugs and they don’t care and just say “no clue, ask someone else at Google”

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.

I like this as a policy, might give a brief explanation why 4. You might link to a roadmap for example that makes it clear why the Issue isn’t being prioritized.

The truth is, you’ll have this for any kind of software you’re doing paid or otherwise. Learning how and when to say no is an important skill.

Usually I just tell people that something’s out of scope, or that if it’s in scope, it’s something on our radar, but not at the top of our priority list right now. If it’s the first time someone’s made that request, I’ll often note that.

If somebody gets pushy, just don’t reply.

But there’s also a decent usability rule: the first time users request something, they’re stupid. The third time users suggest something, you’re stupid. That’s obviously not hard-and-fast, but it is important to keep in mind that even if you think the users are wrong on something, at a certain point, if there are lots of them, they may be right.

Whether or not you care depends on the type of OSS project.

Consider applying the exponential back-off technique. Originally designed for firewalls, it works well with annoying people! (particularly Slack etc. with faster rates than below.)

This only really applies when you owe people an answer, so I’m not even sure this applies here. You could simply palm them off politely.

Here is how it works.

Silly request 1: respond within the hour

silly request 2: respond within a few hours

silly request 3: respond the next day

silly request 4: respond within a week

Stand your ground. No one can make you lose your cool or upset you, unless you let them. Politely decline every time and they’ll get the drift, slowly.

And if your product is open source, they can fork it and shovel it themselves.

You’ll become “the guy who doesn’t respond to GitHub issues” and that is going to backfire on you because commercial software, or other projects, or prosoective employers are going to be coming and saying “you see, this open-source software is not or poorly maintained”

I recommend on saying “Thanks for sharing the idea”

Once you have time to work on your project, then you create a new sprint based on a couple of ideas that you or users submitted.

The question of whether to implement the feature or not, is to be answered during product priotization while assessing potential engineering cost and impact of the feature.

Whether the user is annoying or not isn’t directly relevant, and if it is, it should be based on potential reputational risk under the impact score.

> You’ll become “the guy who doesn’t respond to GitHub issues” and that is going to backfire on you because commercial software or other projects are going to be coming and saying “you see, this open-source software is not maintained”

I fail to see how it would be a bad thing.

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 😉

Just another point to consider: sometimes reviewing a PR and getting it up to your standards is significantly more work than doing it yourself.

If you don’t have time to implement it, there is a chance you don’t have time to review it.

If it is like that, you can simply say you don’t have the bandwidth to review, and/or you don’t want the feature in your repo. You can emphasize that they can always simply fork the project and do whatever they want with it.

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”

> You are free to fork it and maintain your own version

I’d leave that out. That’s unnecessary as it’s an implied freedom of oss, and it can come off as aggressive / dismissive.

I’ve often received positive feedback from software creators in the form of:

“Thanks we will consider it.” Or “Thanks we have passed this on to our developers”

I think that’s a great response without any obligation on either party. People that make a request just want to contribute to the succes of the project because they like it, in my experience.

> 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.

I think this where some bureaucracy would be in order. Have a list of rules somewhere for the project. Have a list of close reasons based on the rules. One of them will be “Feature Request Declined”. With the rule being “If you ask for a feature, we will consider it but we cannot guarantee to implement it, we may close it with Feature Request Declined because of time constraints, priorities or just that the maintainers need a life outside of doing this.”.

This might take the emotion out of it.

“Hi,
Sorry but I/we don’t have time for this feature, there is more urgent stuff that we need to work on. Also remember that we do this for free.
So either do it yourself and make a PR or pay someone to do it, but we won’t.
Have a great day”
close the discussion, if they reopen one, close it again until they get tired
is it that hard?

This response comes off as a bit rude and presumptuous b/c it sounds like you’re accusing the Issue creator of saying “you have to make this”. That’s not clear from the OP. It would depend on what they wrote exactly in the Issue.

In the opening post, it sounds like they’re pitching an idea to get on a roadmap. I would let them know where something like the suggestion lands on the roadmap or if it’s too far down to consider.

I wouldn’t shut down an Issue idea like this unless you want to let everyone know you’re not taking any suggestions.

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).

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.

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

If you don’t intend to merge the feature, you should not say that patches are welcome, that’s an asshole move.

If you’re not sure, say that and that they can open a pr but you can’t make any promise.

If you’re not interested in the feature and are not willing to maintain it, say that as well.

I agree. I think this is what is missing from other responses. What is the problem?

1. This feature is deemed unwelcome and even the most beautiful patch would be rejected. AKA I don’t want to maintain it or the feature is actively harmful.

2. Unsure about this feature, but maybe a good patch would be accepted.

3. The feature is fine, but I have no interest in working on this. Patches are welcome.

I think valuable information to the other person 1. I guess they should go away or fork. 2. Maybe discuss more, maybe find a way to get a patch written. 3. Wait or find a way to submit a patch.

Many people also don’t appear to understand that code comes with an on-going maintenance cost. Even if someone else writes a PR, I may not want to be responsible for that code in future. It’s OK to just say no.

If you’d merge such a feature

– Close issue -> “Feel free to make an implementation and open a PR”.

If you’d not merge such a feature

– Close issue -> “Feel free to fork the project and have an alternate implementation”

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”

the truth is, pr’s might not even be welcome and thats ok. Any code/feature added, even via someone elses PR becomes a maintenance burden on the maintainer.

Remind them they are welcome to fork the project to add what they would like.

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.

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”.

Thank you for developing something people think is worth using and for
being a nice enough person to feel awkward about disappointing
anyone. A charitable assumption is that the requester stumbled on to
github and has mistaken it for his computer vendor’s technical support
channel the way people used to do on AOL. I agree with everyone’s
advice and would suggest in addition only that you be explicit about
your wish list policy in your README. I have such a section in mine
but won’t post it here because it’s probably too snarky for a nice
person.

The suggestions posted here (give a quote, say no, say you are not interested) are part of a larger, useful guideline:

Respond by specifying clearly what would be required for this feature to land in your code.

This can be money, this can be someone stepping up to do it and maintain it, this can be technical requirements under which you can see this go into your framework. Yes, users opening issues are demanding, but as a github repo owner you can ask for anything as well and put up barriers that the user needs to solve to see it happen. They may be motivated too.

Specifying clearly the problems and what is needed to overcome them leads the user to appreciate you more. It will sharpen your thinking on why exactly you are saying no. And sometimes you will be surprised by someone actually making you happy by meeting your requirements.

“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.

You may even want to tell them that their feature will be on a separate branch and any maintenance, including merges from the mainline code, will also be for a fee.

Also, if they want to see your reasoning why you don’t like the proposed feature, they will also have to pay up, because it costs you time to write that down.

“I am not planning to implement this, but it sounds like a good idea, feel free to send a pull request”

additionally apply label “PR welcome” and/or close issue

————

“This feature is out of scope and not planned”

additionally close issue and optionally apply label “declined”

Ideally, you can also drop link to some documented project vision.

————

Other comments have good hints how you can try explaining things.

————

Note that on GitHub and any decent platform you can lock discussions and block people. Feel free to use this, you are not hired by them.

Github could do well to help here. In LinkedIn for recruiters you have auto responses “I’m not interested” etc. Github could do something similar, possibly with a “mute this conversation” option. And if someone is getting muted a lot maybe it’s time to restrict that account or give them some kind of nudge towards improving their behaviour.

Maybe posting a guide to saying you’re not interested is a stronger statement than a button? For example, the guide could suggest creating a label that you use when something won’t be prioritised given present conditions. Or whatever is the direct-but-not-offensive way to reject a request.

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).

I’m no dev but let’s say that my job has a similar issue. The approach that I use focuses on being 1) truthful, 2) clear, 3) polite, 4) concise. In this specific order.

In other words: “Sorry, I’m not going to do this because [insert here the actual reason, not some lame excuse]”.

Past that, if that user keeps insisting, the user is being entitled and you should not bother yourself with entitled people.

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.)

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.

Then comes the next issue:

I really don’t like this feature and then direction it will take my project, but this guy has spent hours and there isn’t anything technically wrong with the code so I cannot reject it for that reason.

Source: been there, done that, someone out there now hates my guts.

Right, so it’s much better to scope the change first – responding to the feature request with this. Either it’s out of scope or one can talk about what part of it would be in scope. Lots of projects have a policy of “talk to the devs before making big changes”.

I would usually indicate negatively on the feature request if I don’t believe it’s in scope.

Add a section to your README file, detailing your vision, the features you plan to implement and features you plan NOT to implement.

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.

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.

I think this is a massive issue for both of you and I don’t know how we can resolve it.

Because it’s an issue for you because you don’t have time to work on it and you can’t always work for free.

But most people are on the other side. They work for a company and the company want them to use a package. But the package doesn’t work or doesn’t have the feature they need.

The can’t fix it or add the feature because their company don’t give them time to read thousand of line of code and fix the bug or even worse, they just don’t have the skill for it. What are they suppose to do ? Their company will put pressure on them and they are stuck so they ask you to fix the bug/add the feature.

In the head of the manager the library is “famous”, it is suppose to work and thousand of developer are using it. If it doesn’t work it’s because the company’s developer is bad. But it’s not his fault too. So everybody is in the same shit.

And it’s a very recurring situation. I’m an average python developer, yesterday my task was to add celery to our django project. Celery is an old and massive “famous” project. It is suppose to work. But what happened when you follow the tutorial ? The tutorial doesn’t work. What do I say to my manager ? Sorry the project sucks it doesn’t work. He will not understand me. I had to follow another tutorial made by someone else and their install guide was different from the official one, and it kinda works. “Kinda” because it didn’t work, to start Celery, celery needs to load the django settings. My django settings was using environment variable. It works for all of them except the django.SECRET_KEY. Why ? I have no idea, so I had to hardcoded the secret key in the settings which is not a good solution, but at least it works and I can progress on the feature I have to do.

What am I suppose to do ? Create an issue in celery asking for “please, can you fix your getting started because my company want me to use celery but it doesn’t work ? Can you create a tutorial for using celery beat with django because my company want me to use it and I don’t know how to do it ?”

Of course I didn’t create an issue because I know I will not have an answer and it’s always my fault because I can’t debug the library for hours to find a solution to the shitty tutorial who doesn’t work.

And that’s just the type of the iceberg, I use all my day to make it work and I didn’t manage to do it. I had to try different package, downgrade setuptools because one package wasn’t compatible etc. At the end of the day, my environment was fucked up, django didn’t even start anymore and I had to erase my environment and create a new one.

And that’s the day of every average developer (so not HN developers). We get angry because nothing work, our company put pressure on use, and at the end, we ask coldly on github for bug fix or feature.

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