21–30 of 243 posts
I had ended up codifying [1] my stance around this to a contrib document to quickly link to annoying issues when closing them. Saves the headache of having to write fresh explanations.
[1] - https://github.com/knadh/listmonk/blob/master/CONTRIBUTING.m...
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 a team maintaining a project, you need to agree with the team on that, obviously.
But keep in mind: random Github users are just random Giuthub users, random people. Treat them with the respect they deserve. If they don't deserve a lot, just close their issues.
The tactic is to add progressively larger delays to each response, while make them shorter at the same time. Start with a delay of a couple of days and progress to weeks. This works and it's very effective in discouraging this sort of behavior.
The same works with for new tickets, but you can just close them after a week. Optionally add something like "Dully noted, thanks".
You don't have resources for that (I presume), and clarify this is (IMO) the appropriate, neutral, answer; that's all.
There is also another sneaky approach. You can add that you're open to commercial support, and to contact you in private for the details. I think this is also understandable, but better be careful. This will surely put things in perspective to the user.
(background: I'm a maintaner myself, although I've never dealt with abusive users; I did make it very explicit though, when I didn't have resources, and users were always understanding).
If so, something I see a lot which I quite like is along those lines - not something the maintainers are interested in (or whatever) so unlikely to be implemented, however high quality PRs will be considered.
Probably you're right, and they'll never offer one. But if you'd genuinely consider and perhaps merge one if they did, I think this is a good outcome for everybody.
(Plus then you can leave the issue open which can be appeasing - and catch others requesting the same - just lock it if necessary as nothing further to discuss without a PR which can be discussed in its own comments.)
Instead of convincing them that it's a bad feature or talking about why it's uninteresting to you, just point them to a CONTRIBUTING.md and stop engaging with them after that. If they're actually serious about the feature, they can implement it in their own fork (which then you can request as a PR if you want it in your repo).
I'm not really interested in adding this. We can discuss the feature further if you're willing to fund it, or to implement and maintain it yourself for the foreseeable future. Otherwise I'm considering the issue closed.
Just reply something like "This feature does not interest me, but patches are welcome!" and leave it at that. This does not mean you actually will merge any PR for said future, should they ever materialize.
> This does not mean you actually will merge any PR for said future, should they ever materialize. If you don’t intend to merge the feature, you should not say that patches are welcome, that’s an asshole move. If you’re not sure, say that and that they can open a pr but you can’t make any promise. If you’re not interested in the feature and are not willing to maintain it, say that as well.
1. This feature is deemed unwelcome and even the most beautiful patch would be rejected. AKA I don't want to maintain it or the feature is actively harmful.
2. Unsure about this feature, but maybe a good patch would be accepted.
3. The feature is fine, but I have no interest in working on this. Patches are welcome.
I think valuable information to the other person 1. I guess they should go away or fork. 2. Maybe discuss more, maybe find a way to get a patch written. 3. Wait or find a way to submit a patch.