Live data from Hacker News

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

news.ycombinator.com

111–120 of 243 posts

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

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

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

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

That also describes my day job.

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

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

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

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

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

#115

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…

When I was a consultant with better manners than I have now, this was the right response to the constant stream of scope increasing requests on fixed time or budget projects.

“That’s a great idea! I’m gonna write it down here as something for V2.”

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

#117
post #109
post #35

Earlier quoted context omitted.

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

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

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.

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

#118

Earlier quoted context omitted.

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.

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

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

#120
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 with the console open)"

It is completely is incongruent with what you have written here. Again, your project, your time, but this is almost tricking people into expecting something that they shouldn't expect. Personally, I have no problem with maintainers using stale bots, but please tell me about it so I can avoid wasting my time on those projects.

Post reply on HN