Skip to content(if available)orjump to list(if available)

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

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

241 comments

·August 6, 2022

Feeling very upset about a feature request.

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.

Even if I don't like it, they keep saying this is very good feature, blabla...

What should I say? F... off?

For these kinds of people, they will never understand the manner of GitHub and do some PR.

And they won't pay at all...

zimbatm

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.

jhauris

This is great communication advice. Your original state sounds a lot like the "asker" vs. "guesser" cultural problem [1]. I've found putting a label on those two outlooks to be very helpful.

1: https://www.theatlantic.com/national/archive/2010/05/askers-...

austinjp

I'd add "teller" to that list, distinct from "asker". I certainly have friends and family who will tell me in no uncertain terms that we're joining them for a meal, or even that they are joining us for our holiday, etc. Brazen barely describes it. They're rare, fortunately, but they exist.

animal_spirits

Thanks for this link. I found this a really interesting way to think about social etiquette.

sandreas

If you would like to see an example of a polite and meaningful discussion I had with a maintainer declining my feature request, you could read this:

https://github.com/nblumhardt/serilog-timings/issues/52

But I would not expect every requester to be polite and accept a NO...

soneil

That really is a great example, but it's very noticeable that you both went into it with the perfect attitude (and maintained an awareness that each had different needs & goals).

It's the "Veruca Salt" case that's much more difficult to solve for.

sandreas

Absolutely...

I tend to first be polite, and then after some conversation do just nothing in this case... don't feed the troll

carvking

It would be a really cool feature :)

sandreas

Thanks. Hehe, yes indeed. But you can't always get what you want...

dt3ft

Perfect example, thanks for sharing.

sandreas

You're welcome :-)

the_gipsy

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

zimbatm

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.

the_gipsy

Sometimes projects "go" earlier precisely because they keep adding shit. Others are eternal because they keep a very narrow scope with high quality.

Freak_NL

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.

tut-urut-utut

Why pointing out something that is a distinguishing feature of open source?

I don’t need your permission to fork off the license allow me to, but telling me that I’d like putting a comment like „btw, did you know that 2+2=4“.

null

[deleted]

klenwell

Excellent advice. This is like the golden rule of dealing with people. Well, the other golden rule. The professional one, I guess you could call it. Be explicit, polite but firm.

It works well for both managing people or doing customer support. It doesn't work for everyone. But as you note, it works in the vast majority of cases.

If you've read the Ask a Manager column, you'll recognize it as a core principle there. And if you've ever watched The Dog Whisperer, you quickly discover it works for dogs, too. (You just have to learn a few tricks for communicating with them.)

perrygeo

In the same vein, it helps to have publicly-stated design goals and constraints on the project. Often the most frustrating feature requests go against the grain of the software's original intent or architecture. To the extent you can articulate that in your software's docs, you can avoid much the misunderstanding.

I see this often with feature requests for backwards incompatible changes, code that would increase the complexity or burden of maintenance, introduce inappropriate dependencies, break APIs, or hurt performance. Often the requester simply never considered these things, either due to inexperience or lack of attention to detail. It helps to have a pre-canned response that you can link quickly.

Responding with RTFM can feel passive-aggressive to some people. But the alternative - writing out a full response to every request - is stressful and time consuming. The subtle shift from "my personal boundaries" to "the project's boundaries" makes communication a bit less strained.

d99kris

I think this is a good advice.

To add on, for some of my projects I explicitly list out-of-scope areas in the README to give users a better idea on where the project boundaries lies.

Kye

This is especially true because the closer you are to limits, the more a reasonable and politely written request can look like a demanding screed from an asshole. It's safer to assume good intentions than risk blowing up on some innocent person.

eternityforest

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

jrib

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?

mytherin

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.

ohwellhere

That also describes my day job.

YetAnotherNick

If not, the maintainer could say "feel free to fork it".

hugh-avherald

This comment would invite argument ("a bit out of scope", i.e. if it were slightly modified I'd be open to it), which is what OP is trying to avoid.

ByThyGrace

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

Accompanied by something like a "WONTFIXMYSELF" tag?

junon

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.

kkirsche

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.

danpalmer

I think that statement should only come after something that justifies it.

The statement implies that the requester is acting in bad faith. If they are, fine, but if they aren't it's somewhat bad faith to treat them as if they are, and in my experience it can really change the tone of a community when all initial interactions start out assuming bad faith.

junon

As someone who has to deal with a lot of PRs, yes I'm going to tell you this if you're being pushy. Of course I won't say this if you're polite like most people are.

jffry

In OP's case, it sounds like the issue submitter is already being pushy and demanding.

junon

Exactly, that's what I meant. Of course don't just blindly say this to someone who hasn't been rude or pushy.

null

[deleted]

zigzag312

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.

AH4oFVbPT4f8

it would be interesting if github allowed the user to submit the feature request and commit x amount of dollars they are willing to pay to have it implemented. if the maintainer wants to entertain the offer, the two agree, and requestor submits the money to github to hold in escrow until the feature is implemented or the time has expired.

scrollaway

This exists as third party services. IIRC it’s exactly how bountysource used to work.

I think the model never took off enough to be attractive to github to implement on their end. But yea I think it would be cool and more popular if integrated directly in it.

TingPing

Users don't understand costs, especially for certain countries. The biggest bounty I got was like $300 for a solid week of work. Most were a few bucks. It was a waste of everyone's time and money, except BountySource.

papito

But really, people should not put you in this situation and discuss the work they are about to do. After all, we don't do major "surprise" work in the workplace (usually).

jefftk

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.

politelemon

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.

Test0129

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

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

exabrial

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.

Derbasti

I add that if the request is reasonable, I always ask back for something. Usually for a specific use case with code example, or maybe a prototype implementation.

I only ever actually react if the issuer demonstrates that it is important enough to them to put in some work.

Because 95% don't.

flibble

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.

robalni

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

nfhshy68

That sounds like a them problem.

"Pull requests welcome" if you want the feature. "Fork off" if you don't.

robalni

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

tomrod

On the flip side, people need to be okay with "No."

robalni

Yes, a "no" is basically what I think was missing from that example response. Something clear that makes the requester feel like they got a response to their request.

andix

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.

sanjayio

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.

andix

You can do that, but it’s your project, you decide how to handle it. If you’re too lazy to write a roadmap, just don’t. You don’t owe random people on GitHub anything. Also not an explanation. Especially if they’re not treating you well.

Test0129

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.

gaza3g

I notice this too when you start charging money for customizations, suddenly all these requests for enhancements gets re-prioritized to good-to-haves from must-haves.

serial_dev

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.

gala8y

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

serial_dev

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.

II2II

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

skyzyx

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.