Live data from Hacker News

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

news.ycombinator.com

131–140 of 243 posts

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

#131
post #45

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…

Certainly this sounds like an issue for you and your company, but I don't see why it is an issue for the project and its maintainers. Many companies enter into support contracts with vendors whose solutions they adopt to avoid this very problem. The solution seems simple to me, your company should seek a support contract with the vendor, and if that is not possible, find a different solution for which they can. It is…

Because this is an issue with 99% of the companies.

Don't forget you are here on HN with HN developers. 99% of companies will never seek support contract with vendors. That's the reality, developers have to deal with it and get over the struggle. Maintainer have to deal with it too because companies will never change (or at least not in the few months) and get over developers asking for help which have issues with their library.

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

#132
post #81

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…

You are free to do whatever you want, but why not explain in your contributing guidelines that this is how you operate? https://github.com/nodemailer/nodemailer/blob/0b78689e5a8641... The text starts with: "First, thank you for considering contributing to nodemailer! We welcome any type of contribution, not only code. You can help with QA: file bug reports, the more details you can give the better (e.g. screenshots w…

Oh, good point, I should probably update it or remove it. That guide was last updated 5+ years ago, I didn’t even rember that it exists and haven’t been following it for years.

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

#133

Earlier quoted context omitted.

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

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

This whole question in the first place is about people that showed that they don't know such things and so need to be told such things, by the nature of their demands.

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

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

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

#135
"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... :)

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

#136
post #46

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…

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.

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.

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

#137
post #21

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

Those contributing guidelines are very well written. I'll borrow them for my projects!

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

#138
post #77
post #33

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 h…

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 idea…

You're mistaken this as my default response handling. That's incorrect. This is only for the repeated and unsolicited actors who have nothing better to do than make your life a living hell.

The logs will show that you're being responsive, and that this person clearly doesn't let go.

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

#139
post #44

Earlier quoted context omitted.

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.

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

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

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

Post reply on HN