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.

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

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.

One way to think about it:

By making a FR, the user is providing free feedback. This feedback might be useful or not. Still, remember that the user has invested his/hers time to submit the explanation. Be nice if possible. Passionate users can be a bit extreme, so give them some slack. But if the user is not behaving politely, ignore him.

The user has NO idea how expensive would it be to implement this FR. Even developers often have no idea, so don't feel offended, if he/she doesn't know. Communicate it to them so they can manage their expectations.

Don't say you'll do it for X amount of money. The amount will either be too high (unless it's a corporate user) or it'll be too low and you'll be devaluing your work. If you would do it for a fee, tell them they'll probably need to raise some funding for you to implement this feature or hope someone else is prepared to do it for free.

If the feature doesn't fit your vision for this software, thank them for the input and clarify to them that at this time this FR doesn't fit your project. So, they'll need to find an alternative solution for their needs.

My decision tree:

1. Do I think this is a good feature? No -> I'm sorry, I don't think this is a good fit for the project.

2. Am I excited about implementing it? No -> This is a good idea, but I'm not up for adding it right now. If you or someone else wanted to send a PR I'd be happy to review!

3. Am I going to get to this soon? No -> This is a good idea, and something I'd like to add, but I might not get to it for a while. If you or someone else wanted to send a PR I'd be happy to review!

4. If it passes all these filters it's generally something I do right away. Fewer and fewer of these as the simple excellent features have generally all been added.

So far I've found that as long as I'm clear with people no one gets obnoxious. If they did I'd say something about how this is a project I maintain for fun in my spare time.

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.

Kindness first, always. Maintaining an OSS project will push your personal growth to a new limit.

- be direct: I do not wish to have that feature in the project.

- explain: the vision of the project is xyz. This feature you’re requesting does not fit in the vision because abc. I don’t think it belongs here as it will become a maint burden and a distraction from the goal.

- encouragement: if you do think you’d find value, i would encourage you to fork the code. I’d be willing to give you a few pointers on how to implement, but that’s the extent I’m willing to provide help for free.

- disengage: do not argue. Do not create personal attacks, and ignore any thrown your way. If they persist, link back to the original explanation so everything is in one place.

- be willing to be wrong. Sometimes people’s rudeness makes us respond with obstinacy. If you can calm the situation to a civil discussion, do consider their viewpoint and alleged benefits.

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.

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.

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.

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.

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.

Once I posted a super long reply to a super long and messy feature request: https://github.com/database64128/youtube-dl-wpf/issues/131. It's basically like this:

> First of all, thank you for your support...$blah_blah_blah

> Unfortunately, I have to say no to some of your requests. $project is just a small side project of mine. My approach to its development will always be to prioritize my own use cases, while also catering to the community as much as I can. As you may have noticed, I have already implemented a bunch of new features and made quite a few changes based on community feedback. Decisions on whether to adopt a proposal from the community are made by evaluating the usefulness of the proposed feature or change for me and the wider community, and the feasibility of implementing it in my limited spare time.

> Now that I have explained my ways of doing side projects to you, let's go through your proposals:

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

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

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

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"

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.

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”

My responses fall into 3 broad categories:

1. I consider that to be out of scope for this project, but feel free to fork and add it yourself. (Translation: I think it's a bad idea)

2. That's a good idea, I will consider implementing it at some point in the future. In the mean time, PRs are welcome.

3. Sure, I'll implement it now.

If for some reason they keep asking, I respond with something along the lines of "pay me, or go away" (but perhaps phrased more politely, depending on what mood I'm in).

Which of these "no"s are you trying to say?

1. I'm not interested in implementing this feature, but if you pay me then I will anyway

2. I'm not interested in implementing this feature even if you pay me, but if you write a PR for it I'll merge it

3. I'm not interested in this feature at all and don't want it even if you write a PR for it

If it's 1 or 2, then just saying that is good enough. If it's 3, then you should explain a little bit what's wrong with the idea.

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.

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

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

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.

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

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"

"Thank you for your feature request. Submitting thoughtful requests like this takes time, and I appreciate the consideration put in to prepare it.

Unfortunately, the feature request does not align with the goals I've set for this project, and I will not be considering it or any related requests for the foreseeable future. Specifically, I intend to accomplish [your desired outcome of the project] and do not want to reach that goal using the methods you have described.

I sympathise if this is a dealbreaker for you. I have appreciated your patronage up til now, and understand if you need to seek alternative software solutions as a result."

You can follow up with a more "direct" comment if they don't get the message from the above. However this should suffice in most cases.

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.

I tag all new issues that come as “Feature Request”, “Bug”, etc. and then as far as I’m concerned, unless I’m interested in the issue, my work is done.

Those then serve as an excellent roadmap for anyone who wants to contribute, but my projects are built for me and I work on the parts I want and need.

I also use GH automation to auto-close issues after a year. If no one cares enough to implement the change in a year, no one cares.

Your project is yours, feel free to ignore everyone else.

I also highly recommend watching this talk by Pieter Hintjens a couple of times. It is brilliant https://m.youtube.com/watch?v=uzxcILudFWM

(I’m the creator of WTFUtil).

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.

The requester is wrong.

You are the project leader. You are the decider when it comes to the project. Do you think this makes your project better? If so, cool. If not, say so.

If someone is badgering you, then feel free to charge them money for your time. They can choose to sponsor the development of a feature that can be used by everybody. Or they can choose to pay you for custom development that they would own after the transaction.

One thing that I do (in the US) is I have very specific guidelines about the transfer of copyright and licensing. I own the copyright to the code, full stop. I don’t offer copyright for purchase. What I do offer is a long-term, royalty-free license to use that copyrighted software that I give them once payment is made in full.

If they use my code or my designs without a license, then I have the ability to file a copyright infringement case. Thanks to the Recording Industry of America (RIAA), copyright infringement cases can be upwards of $150,000 USD per infringed copy, which can be translated into a download, which can be translated into a website visitor. Very quickly, companies realize that it’s in their best interests to pay what they owe me.

Having said all of that, if you don’t want to do it, then just don’t do it. But you have to have the backbone to say no. Set boundaries for yourself, and then enforce them. But backbone is what makes the world go round.

Mark as 'wontfix' and close. If they reopen, ban them, with a comment explaining why if you want ("I'm banning you because your feature requests are not welcome").

It's really important to communicate that you are distressed. Remember, it's quite likely they think they are not causing any distress, and probably would prefer to know than cause any additional harm. Banning them accomplishes this. It also has the additional benefit that if the person is not being conscientious, they no longer can annoy you.

I have to deal with that frequently and would say, it really depends what you want.

Do you think the issue is useful but you don't want to implement it? Keep the feature request open and say you're open to contributions (or maybe getting paid to implement it).

Do you think it's out of scope and shouldn't get implemented? Say that, close the issue and lock it if people keep discussing.

I can also recommend creating response templates for these things. Be clear and assertive, back and forth wastes everyones time and just leads to more frustration on both sides.

wontfix, close, mute, block.

It is open source, they can always fork it, fix it and do the long term maintenance themslves.

Look at it like this - even big FAANG companies have bots that auto-close issues without discussion. You don’t have to feel bad about closing an issue and locking it.

You can just block them from the repo. If it's using up your emotional energy after you've explained your position, be proactive and push it away. I realise that's the nuclear option, but at some point you have to draw a line - especially when it's your time and your mental health that is being drained away.

I've only needed to do it a couple of times on my projects, but sometimes it's needed.

Keep in mind that if the user doesn't speak English natively they may be coming across more aggressively than they actually mean to.

Move off of GitHub. It's clear that neither the founders nor the new Microsoft management care about this kind of noxious spam. Or at least, they can't be bothered to give you the tools you need to deal with it (I want to be able to, at my discretion, (1) disable creation of issues and pull requests (2) force an approval process where I must approve issues and PRs before they even appear on the page (3) be able to decline PRs without the original poster or anyone else from getting an alert).

The fact that they won't add these features isn't surprising, GitHub is designed to be a corporate product, for corporate dev teams. That's who pays the bills, not open-source projects which are less obviously a benefit to GitHub (they are, they bring corporate users/payers to the platform).

It's clear you don't want to be confrontational in any way. I understand, it's also not in my nature. You shouldn't be forced to deal with this, yet on GitHub, you will be.

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

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.

"Thank you kindly for your suggestion as to how the project can be advanced in a prosperous manner. At present, the project contributors do not possess the bandwidth and time required to implement this feature. Although it is not a present priority for us, we would welcome a patch implementing this feature."

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.

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.

To me it sounds you don't really know why it's not a good idea, but you are just annoyed by the phrasing of the feature request.

So my advice would be:

1. Relax.

2. Take the emotion out of the equation.

3. Actually try to think about the feature request and why you will or will not implement it.

4. Calmly explain your reasoning based on rational grounds.

Don't say no. But don't say yes. Feature requests can live in the issue tracker indefinitely, they aren't an obligation on your part.

If someone is insistent, ask if they're interested in submitting a PR. Or if they're interested in paying for that feature to be developed. If it's small, this is a good way to get some of your amazon wishlist items filled.

If they're being inappropriate, just block them like any other troll on the internet.

If the feature is genuinely something that doesn't make sense for the project, mark it as wontfix and briefly explain why you think it's out of scope. If you're feeling generous, mention some other solution that might solve their problem.

Don't take it personally. It's just some rando on the internet.

I don't understand the problem here. Can't you simply close the issue with a comment like "sorry, I don't have the time, if you want this feature find someone who can submit a proper PR"?

Or even leave it open and tag it as "waiting for external PR" ...

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 have found that a good way to engage in these situations is not to debate their request, but instead to simply state what things you ARE doing and why. So you avoid getting dragged into a discussion.

You don’t need to engage with someone’s question on their terms.

Perhaps you'd be better off not using an open license? Especially if it's related to this https://news.ycombinator.com/item?id=30887004

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

The important part is to close the issue. How you do that depends on the nature of the request.

A #someday tag is a mollifying way of saying "Not on the roadmap, don't hate it, not planning to ever look at this again".

The advantage is: it's not an open issue. Flogging a closed issue is widely understood to be antisocial behavior, and opening a variation on a closed issue is open-and-shut rude.

You can ban someone who does this as an ordinary matter of policy, no one will judge you negatively for it.

As long as it's an 'open issue', a certain class of entitled developer will feel free to harass you about it.

First, decide why you don't want this: Is this a "patches welcome" situation where the change is good but not worth your time, or a change that would make the software worse/isn't a good fit?

Then explain that politely but firmly, and don't be afraid to explain that you're a volunteer working on it, so you ultimately make the calls.

If the reporter becomes uncivil, close and lock the issue. If they start being disruptive/filing new issues, ban them.

(You could also offer paid support, but it seems like you already know that this person wouldn't be a nice customer to work for.)

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.

"No, thank you. That's not something I'd like to add at the moment."

Just be a straight G about it. I've gone after people and make a point to embarrass them if they try to extort me into doing something or make some passive-aggressive comment to goad me. Works a peach.

This attitude, but applied to other developers on Github, not clients: https://medium.com/@menichols/i-aint-scared-of-you-motherfuc....

I have a public roadmap, where people request new features all the time (https://trello.com/b/5i4VvOW8). All of people's features are in there, but some might indeed never happen.

When someone asks or requests, my response is: "Right now I'm working on higher priority things, but some day I might get to your request". It satisfies them all the time, since they understand I'm still improving it, just not their thing.

It's pretty simple. "they won't pay at all": would you want to add the feature if he paid you? Then tell him that.

Don't want the feature? Just say no, close the issue and move on. Especially if your project is MIT licensed, it's crystal clear in the license that very one thing: you don't owe anything to anyone :) You don't need to be nice, you don't need to explain. Life's too complicated to be upset about those things.

If the person keeps on insisting after that, you can block him from GitHub.

If you don't feel your project needs his request, or you just don't want to do it; give him an hourly rate.

He'll figure it out soon enough, no point in wasting your personal time on a stranger.

yea you can say fuck off

well politically correct answer is to fork off

they should fork it instead haha

Say it straight: 'I will not add this feature' or 'I will only add it if you implement it', whatever is the case for you. You could add: thanks for your suggestion or something like that.

That's it. You may give a reason if you want, but don't engage in argument. Just ghost or block them if they persist. Don't have to fight or yell, just let the other deal with their own disappointment. If they misbehave on your project, ban them.

You don't owe anybody anything.

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

read: https://polite.technology/preview --> "Rejecting pull requests" by Tom MacWright

".... Rejection is hard. There are a few key things you can communicate to soften the blow. Like many of the other things I recommend, the underlying strategy is that you need to be explicit about the positive and emotional parts of an encounter, not just the technical parts. It's simple and easy to deliver a code review, but implicit in that review is the fact that someone took the time to contribute, and that should be recognized as well."

"PRESENT THE WAYS OUT

Rejected pull requests aren't a dead end, so don't make them sound like the end. You should encourage everyone to contribute again, and present their options explicitly:

I'm going to close this pull request, but I hope you can contribute in the future! If you need this change, feel free to maintain a fork. ... "

...

"Responding to feature requests

Once a project achieves a certain level of success, it will have users, and those users will have additional demands of the project in the form of feature requests. Experienced and empathetic users will state their feature requests precisely and kindly, but others will use an unfriendly tone or imprecise language that doesn't lend itself to a solution.

- The maintainer does not owe their time to anyone

- The maintainer must treat everyone with respect

"

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.

I'd go with:

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

Why do you need to respond at all? It's perfectly okay to just leave it as an open request. Maybe in the future you'll want that feature, and their feedback will be useful. Or maybe that'll never happen.

If you must respond to them, politely decline, with or without a reason as you like.

If they continue insisting (which it appears they are), just stop responding. You don't owe them anything, and the above still stands.

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

If you are not sure, get the person involved and see how it pans out. If the person requesting can be asked to "do some work" - diagrams, functional spec, mockups, etc, then it shows commitment. Most cases the user might not be interested, so then it fizzles out. If he/she is really passionate about it, it may turn into a good idea since someone is actually giving it proper attention.

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.

Put a link to your Bitcoin public key and tell them to send you $500 or however much you want.

If they don't want to... tell them to send a PR themselves.

This request does not align with my roadmap for the project, but you're welcome to fork the code and implement it with your own team.

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.

"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?

"Thank you for the proposal but unfortunately it does not fit in the scope and vision I have for the application, and I rather spend time on areas that I believe in.

However if this is very important to you, I can consider implementing it for a fair compensation for my time."

Something like that. And ensure that contract doesn't include lifetime support/maintenance... :)

Perhaps you can set a price for it? Could become a win-win although I grant that it is probably not realistic he will jump on it.

You need to understand that the person is using common manipulative behaviours. Here's some help. It'll take a few hours, but here you go:

https://openlibrary.org/works/OL5269976W/When_I_say_no_I_fee...

If I think it's actually a good idea, I tell them I'll happily accept a pull request. I've had dozens of feature requests but only once has someone actually taken me up on this.

If I don't think it's a good idea, I'll give reasoning why and close the issue. If they reopen the same thing I'll ban them. Very simple.

I appreciate this approach to the massive entitlement: «Minecraft 1.18.30.04 support will be added to linux April 19, 2023.»

https://github.com/ChristopherHX/mcpelauncher-manifest/issue...

Along with "Feature Request" and "WONTFIX" perhaps an option of "Maybe Someday" could make it clear that it's a known request but it's very much not on the top of the priority list.

Edit: maybe also "Poor Fit" for things that are between "someday" and "never."

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.

"Thanks for opening an issue. For reasons I'd rather not elaborate on, I must decline the request"

This is probably not best practice but I just throw it in the backlog. There's always too much stuff in the backlog. Maybe theoretically someday another dev will write it and submit a PR. Maybe the requester will.

This doesn't apply as well if it's a feature you actively do not want in the product.

A mate of mine wrote about this a couple of years ago.

> The three F’s to open source development. > Fix it, Fork it, Fuck off.

https://boyter.org/posts/the-three-f-s-of-open-source/

I don't even let paying customers make feature request lists. Lol. If they want a feature they can ask directly in a chat message. If it's not one of the one or two priorities that are next then we can discuss it on the following iteration in a few days or a week.

Honestly I think you should try to state exactly how you feel (F off) in the most professional and non-abrasive way possible. What do you really want to say to this person? Do that.

The important thing is to speak your truth. You don't owe anyone else anything in this life!

For these kind of people, I just stop responding.

I try to respond to every feature request I get, but when people start to argue, and I have nothing to say that moves the discussion forward, I just stop responding.

When they don't get a reply, they tend to forget about it and stop arguing.

Put that issue in backlog. May be someone will implement it. I don't think it's necessary to be rude in that case. Of course it's up to you, it's your project and you're not owing anyone to do anything.

If the feature isn't something on your roadmap, and it is important to you, or important enough for them to contribute brue code themselves, then politely say, "not on our roadmap" and close the issue.

Politely, but firmly inform them that you will be willing to take his pull request under consideration when he's implemented the feature, and that, if it is not rejected, may be included in a future release.

Ask for a six figure donation

“No.”

Then close it. Then ban him if he persists.

There’s no need to waste your time and energy justifying yourself. In fact, attempting to will probably be taken as an invitation to argue, thus wasting even more of your time and energy.

Create a label “no bandwidth” or “f… off” if you prefer - then close it.

Just say no. How is this hard?

If you don't stand up for yourself in life, you're opening the door for people to take advantage of you. Don't let the perceptions of others control you

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.

use language like this:

"Unfortunately I only have limited resources to maintain XYZ, and such a feature add would increase my maintenance and testing burden beyond that which I'm able to accommodate. Feel free to fork my work and/or use competing product QPR""

that's assuming even if they paid you, you still wouldnt want to do it. if you are willing to add the feature for money, that's easy, just ask them for money. often they will

“ I currently don't do free support for this project. If you have a budget, then I can make time. Let me know.”

And then I closed the issue. I can’t see any problem with this.

I try to inform users as much as possible re our boundaries and how we prioritize feature requests within the Github issue template.

I think it helps, but it's not bulletproof.

Easy: Just say " My time is not free, if YOU want this feature you need to pay $100000. If you are unhappy with that, do it yourself."

I’m sorry but I’m not willing to implement this feature. Feel free to fork the project and implement it by yourself if you want.

Regards, $YOUR_NAME.

Just curious, what open source project are you working on? No, I am not going to ask for feature requests or anything like that ..

Just say no. You don't owe them anything except common courtesy. Once you have told them no twice you can just ignore them.

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

"Nice idea, you should get someone to implement this. Not me, I only maintain the software features as I need them."

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.

Common, these are only two letters. N and O.

Some open source software users feel entitled instead of grateful for what they receive.

Rich Hickey's "Open Source is Not About You" essay gives perspective about the creator / maintainer point of view:

https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...

I would offer a polite decline and point the user to the essay.

some suggestions:

- "pull requests welcome" (This is the polite way to say 'fuck off') - "thanks for sharing your feedback, I don't think this is a feature I'm willing to build or support" - "in order to implement this I would need to be compensated" - "no."

"No" and then close the issue. Don't give them the idea that they can talk their way out of it.

Does GitHub provide a way for maintainers to rank features/issues, or allow users to vote for them?

Tell them they are right and ask them to fork and build it and send the changes for your review.

I would say: "Feel free to open a PR with the proposed changes".

Because if they want the thing that bad... come to the table with an example. Then you can still reject that. It's not like you're forced to add something to your code you don't want. They can fork the code if they need that so desperately.

"wontfix"

Then close the issue and ignore it. People are not entitled to your time for free.

I would offer them to join the project as a collaborator or just stop responding.

"Thank you for the suggestion. I have decided not to implement it."

The option of not answering, or very later, is often a pretty effcient one

Thank them for their request, say you're busy, never implement it.

Just link them to this discussion. Hopefully they'll catch on.

The normal answer would be: thanks, send a pull request if you want.

"PRs welcome".

If the source code is there they can do it themsleves.

No is a full sentence.

F... off, where "F" stands for "fork".

wontfix and close. If you're feeling generous invite them to make a PR. You don't owe anyone an explanation. Let them fork if it suits them.

"Closed as Won't Do", then move on

You're under no obligation to even respond

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

Feel free to create a pull request

“Please provide a patch/PR”

Give them their money back.

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.

Closed as Won't Fix

Request denied

Your magic word is "scope". Seperation of concerns.

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'd close the ticket without a response