Ask HN: How to say no to a GitHub issue feature request? • Hacker News Board

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

#91

Post by prmoustache » Sat, Aug 06, 2022, 11:45 AM UTC

rvnx wrote: post #77

keyle wrote: 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'll become "the guy who doesn't respond to GitHub issues" and that is going to backfire on you because commercial software or other projects are going to be coming and saying "you see, this open-source software is not maintained"

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

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

#92

Post by sanjayio » Sat, Aug 06, 2022, 11:45 AM UTC

andix wrote: post #22

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

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.

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

#93

Post by sanjayio » Sat, Aug 06, 2022, 11:48 AM UTC

nicbou wrote: post #3

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

This can come off as rude if you’re trying to make a collaborative project. I’d link to a roadmap or be honest and say this doesn’t pique your interest.

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

#94

Post by samatman » Sat, Aug 06, 2022, 11:50 AM UTC

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.

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

#95

Post by Kye » Sat, Aug 06, 2022, 11:51 AM UTC

zimbatm wrote: post #69

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…

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.

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

#96

Post by andris9 » Sat, Aug 06, 2022, 11:53 AM UTC

rvnx wrote: post #86

andris9 wrote: 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…

Is it a product made by employees of EmailEngine or how does it work ? Intuitively I would find it super rude if commercial companies just ignore or send people away for open-source tooling that is directly used for their commercial product. Like when there are Google APIs Python Client bugs and they don't care and just say "no clue, ask someone else at Google"

Nodemailer is a project I started 11+ years ago with no backing. It gets millions of download every week and is used by hundreds of thousand of projects and developers around the world.

EmailEngine is a commercial project I started a year ago and now I use the Nodemailer’s homepage to drive traffic to it. Both are my solo projects, no one else is involved.

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

#97

Post by Retr0id » Sat, Aug 06, 2022, 11:55 AM UTC

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

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

#98

Post by sgt » Sat, Aug 06, 2022, 12:00 PM UTC

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.

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

#99

Post by soneil » Sat, Aug 06, 2022, 12:02 PM UTC

sandreas wrote: post #82

zimbatm wrote: post #69

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…

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

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.

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

#100

Post by dt3ft » Sat, Aug 06, 2022, 12:03 PM UTC

sandreas wrote: post #82

zimbatm wrote: post #69

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…

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

Perfect example, thanks for sharing.