Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

71–80 of 243 posts

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

#71

Post by mytherin »

jrib wrote: post #44
eternityforest wrote: post #34

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

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.

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

#72

Post by kramerger »

nivenkos wrote: post #42

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

Then comes the next issue:

I really don't like this feature and then direction it will take my project, but this guy has spent hours and there isn't anything technically wrong with the code so I cannot reject it for that reason.

Source: been there, done that, someone out there now hates my guts.

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

#74

Post by the_gipsy »

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…

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

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

#76

Post by gpvos »

inglor_cz wrote: post #32

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

You may even want to tell them that their feature will be on a separate branch and any maintenance, including merges from the mainline code, will also be for a fee.

Also, if they want to see your reasoning why you don't like the proposed feature, they will also have to pay up, because it costs you time to write that down.

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

#77

Post by rvnx »

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 ideas that you or users submitted.

The question of whether to implement the feature or not, is to be answered during product priotization while assessing potential engineering cost and impact of the feature.

Whether the user is annoying or not isn't directly relevant, and if it is, it should be based on potential reputational risk under the impact score.

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

#78

Post by FrenchDevRemote »

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

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

#79

Post by pacifika »

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.

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

#80

Post by wheels »

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.

Post reply on HN