121–130 of 243 posts
It is open source, they can always fork it, fix it and do the long term maintenance themslves.
Look at it like this - even big FAANG companies have bots that auto-close issues without discussion. You don’t have to feel bad about closing an issue and locking it.
Unfortunately, the feature request does not align with the goals I've set for this project, and I will not be considering it or any related requests for the foreseeable future. Specifically, I intend to accomplish [your desired outcome of the project] and do not want to reach that goal using the methods you have described.
I sympathise if this is a dealbreaker for you. I have appreciated your patronage up til now, and understand if you need to seek alternative software solutions as a result."
You can follow up with a more "direct" comment if they don't get the message from the above. However this should suffice in most cases.
".... Rejection is hard. There are a few key things you can communicate to soften the blow. Like many of the other things I recommend, the underlying strategy is that you need to be explicit about the positive and emotional parts of an encounter, not just the technical parts. It's simple and easy to deliver a code review, but implicit in that review is the fact that someone took the time to contribute, and that should be recognized as well."
"PRESENT THE WAYS OUT
Rejected pull requests aren't a dead end, so don't make them sound like the end. You should encourage everyone to contribute again, and present their options explicitly:
I'm going to close this pull request, but I hope you can contribute in the future! If you need this change, feel free to maintain a fork. ... "
...
"Responding to feature requests
Once a project achieves a certain level of success, it will have users, and those users will have additional demands of the project in the form of feature requests. Experienced and empathetic users will state their feature requests precisely and kindly, but others will use an unfriendly tone or imprecise language that doesn't lend itself to a solution.
- The maintainer does not owe their time to anyone
- The maintainer must treat everyone with respect
"
Then explain that politely but firmly, and don't be afraid to explain that you're a volunteer working on it, so you ultimately make the calls.
If the reporter becomes uncivil, close and lock the issue. If they start being disruptive/filing new issues, ban them.
(You could also offer paid support, but it seems like you already know that this person wouldn't be a nice customer to work for.)
Rich Hickey's "Open Source is Not About You" essay gives perspective about the creator / maintainer point of view:
https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
I would offer a polite decline and point the user to the essay.
- be direct: I do not wish to have that feature in the project.
- explain: the vision of the project is xyz. This feature you’re requesting does not fit in the vision because abc. I don’t think it belongs here as it will become a maint burden and a distraction from the goal.
- encouragement: if you do think you’d find value, i would encourage you to fork the code. I’d be willing to give you a few pointers on how to implement, but that’s the extent I’m willing to provide help for free.
- disengage: do not argue. Do not create personal attacks, and ignore any thrown your way. If they persist, link back to the original explanation so everything is in one place.
- be willing to be wrong. Sometimes people’s rudeness makes us respond with obstinacy. If you can calm the situation to a civil discussion, do consider their viewpoint and alleged benefits.
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…
"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…
Accompanied by something like a "WONTFIXMYSELF" tag?
Some open source software users feel entitled instead of grateful for what they receive. Rich Hickey's "Open Source is Not About You" essay gives perspective about the creator / maintainer point of view: https://gist.github.com/richhickey/1563cddea1002958f96e7ba95... I would offer a polite decline and point the user to the essay.
They’re pretty rude / brash in communication, which is fine, but I wouldn’t look at them for an example of great OSS stewardship.