231–240 of 243 posts
You don’t need to engage with someone’s question on their terms.
https://openlibrary.org/works/OL5269976W/When_I_say_no_I_fee...
Earlier quoted context omitted.
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 th…
Earlier quoted context omitted.
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 th…
I suspect the maintainers will just ignore these kinds of requests, rather than "get over" them. If you and your company want help, you'll need to pay for it. That's the reality. If your company won't pay for it, then you'll have to "get over" your app not working.
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…
"I am not planning to implement this, but it sounds like a good idea, feel free to send a pull request" additionally apply label "PR welcome" and/or close issue ------------ "This feature is out of scope and not planned" additionally close issue and optionally apply label "declined" Ideally, you can also drop link to some documented project vision. ------------ Other comments have good hints how you can try explainin…
Yeah but I guess the issue then becomes, what happens if the PR ever materializes? Would you want to maintain that code now?
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 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-...
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…
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.
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.
Earlier quoted context omitted.
That sounds like a them problem. "Pull requests welcome" if you want the feature. "Fork off" if you don't.
> 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…